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Air  Force  Systems  Command  (AFSC). 

The  series  of  Software  Acquisition  Engineering  Guidebooks 
(Airborne  Systems)  is  currently  planned  to  cover  the  following  topics: 
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1.  INTRODUCTION 


1.1  PURPOSE  AND  SCOPE 

The  purpose  of  this  guidebook  is  to  assist  Air  Force  Program 
Office  and  engineering  personnel  to  interpret,  select,  and  apply  regulations, 
specifications,  and  standards  (RSS)  to  the  acquisition  of  airborne  system 
software. 

This  guidebook  describes  the  structure  and  functions  of  the  RSS 
system  of  documents,  emphasizing  areas  of  special  importance  for  air- 
borne system  software  acquisition  under  the  800  series  of  Air  Force 
regulations,  and  explains  both  the  obligations  of  an  acquisition  program 
to  comply  with  certain  RSS  and  the  vital  support  that  other  RSS  will 
provide  in  the  establishment  of  requirements  for  contract  compliance. 

This  guidebook  describes  how  to  select  appropriate  RSS  for  contractual 
compliance,  how  to  tailor  them  for  maximum  effectiveness,  and  how  to 
reference  them  in  the  contract  documents.  It  also  explains  how  to  develop 
an  entire  set  of  data  item  ( i.  e.  , documentation)  requirements  for  a soft- 
ware development  program.  Finally,  it  contains  summaries  of  key  RSS, 
an  RSS  bibliography,  a list  of  related  guidance  documents,  and  lists  of 
definitions,  abbreviations,  and  acronyms. 

1.2  CONTEXT  OF  RSS 

1.2.1  RSS  Within  the  System  Life  Cycle 

The  greatest  value  of  regulations,  specifications,  and  standards 
for  a procurement  is  their  ability  to  establish  common  acquisition 
directions  and  goals  for  Government  and  contractor  personnel.  To 
accomplish  this  task  effectively,  the  RSS  must  be  selected,  tailored, 
and  applied  early  enough  to  be  assimilated  and  implemented  in  their 
intended  manner. 


The  general  path  that  a program  should  take  in  establishing  its 
RSS  requirements  at  the  start  of  an  acquisition  is  defined  by  HQ  USAF 
in  a Program  Management  Directive  (PMD).  The  PMD  may  identify 
regulations  within  the  AF  800  series  that  are  to  be  followed  and  also 
some  regulations  not  to  be  followed.  From  this  general  RSS  baseline, 
a program  must  develop  successive  levels  of  RSS  requirements  that 
will  carry  it  through  the  entire  acquisition  process  and  sustain  the 
operating  and  supporting  commands  thereafter.  This  entire  structure 
of  RSS  should  be  identified  by  the  end  of  the  conceptual  phase,  even  though 
some  items  still  are  tentative.  By  the  end  of  the  validation  phase,  the 
Program  Office  should  have  established  the  definitive,  tailored  set  of  RSS 
that  will  guide  it  and  all  other  program  participants  through  the  full-scale 
engineering  development,  production,  deployment,  and  operation/ 
maintenance  phases. 

1.2.2  RSS  Within  the  Guidebook  Series 

This  guidebook  is  only  an  introduction  to  the  RSS  system  and  a 
general  account  of  its  application  to  the  acquisition  process.  The  other 
volumes  of  this  series  contain  the  detailed  guidelines  for  interpreting, 
evaluating,  and  applying  the  particular  RSS  that  are  appropriate  to  their 
special  subject  matter. 

This  guidebook  has  many  links  with  two  others:  "Contracting  for 
Software  Acquisition"  and  "Statements  of  Work  and  Requests  for  Proposal." 
It  also  has  close  connections  with  "Computer  Program  Documentation 
Requirements."  For  the  other  guidebooks  in  this  series,  it  is  an  impor- 
tant support  document. 

1.3  CONTENTS  OF  THE  GUIDEBOOK 

This  guidebook  contains  the  following  parts: 

• Abbreviations  and  Acronyms.  A list  of  abbreviations 
and  acronyms  used  in  this  guidebook. 

s Section  1,  Introduction.  Describes  the  purpose  and  scope 
of  this  guidebook,  states  the  general  functions  of  RSS  within 
the  system  acquisition  life  cycle  and  within  this  guidebook 
series,  and  outlines  the  contents  of  this  guidebook. 


- 2 - 


• Section  2,  Software  Acquisition  LifeCycle.  Briefly  describes 
defense  system  life  cycle. 

• Section  3,  RSS  System.  Provides  an  overview  of  the  entire 
RSS  system,  discusses  the  importance  and  characteristics 
of  the  AF  800  series  of  RSS  to  software  acquisition,  and 
briefly  examines  other  useful  RSS. 

• Section  4,  Using  RSS  as  Compliance  Documents.  Discusses 


the  process  of  referencing  RSS  as  compliance  documents, 
general  procurement  and  contractual  considerations,  and 
selection  and  tailoring  of  RSS. 

• Section  5,  Defining  Program  Data  Items.  Describes  the 


entire  procedure  for  establishing  program-peculiar  data 
item  requirements.  Discusses  Data  Item  Descriptions 
(DIDs),  the  Data  Call  process,  and  several  alternate 
documentation  standards. 

Appendix  A,  Summaries  of  Key  RSS,  Summarizes  key 
RSS  having  particular  significance  for  acquisition  of 
airborne  systems  with  software  components. 

Appendix  B,  RSS  Bibliography.  Lists  several  hundred  RSS 
that  have  some  relation  to  software  acquisition  management 
and  development  tasks. 

Appendix  C,  Related  Guidance  Documents.  Lists  several 


guidebooks  outside  this  series  that  offer  useful  information 
on  RSS  and  software  data  items. 

• Appendix  D,  List  of  Definitions.  Defines  some  basic 
software  acquisition  terms. 

A pocket  at  the  end  of  this  guidebook  contains  a wall  chart  showing 
basic  documentation  requirements  for  the  entire  life  cycle  of  a medium 
or  large  software  development  program. 

The  titles,  numbers,  and  dates  of  the  RSS  discussed  in  this  guide- 
book, including  Appendices  A and  B,  are  based  on  the  latest  information 
available  at  the  time  of  publication.  Before  RSS  are  used  or  referenced 
in  an  acquisition,  the  latest  official  Government  indexes  should  be  con- 
sulted to  determine  if  they  are  still  current. 
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2.  SOFTWARE  ACQUISITION  LIFE  CYCLE 

The  normal  weapon  system  acquisition  life  cycle,  as  defined  in 
AFR  800-2,  "Program  Management,  " and  in  more  detail  in  AFR  800-3, 
"Engineering  for  Defense  Systems,  " consists  of  five  phases:  conceptual, 
validation,  full-scale  engineering  development,  production,  and  deployment. 
Figure  2-1  shows  these  phases  together  with  the  major  tasks  for  both 
software  (CPCI)  and  hardware  (Cl)  development,  related  design  reviews, 
configuration  audits,  baselines,  and  the  four  milestones  defined  by 
DODD  5000.1. 

Software  development  proceeds  through  the  system  life  cycle 
essentially  in  the  same  manner  as  hardware  development.  The  major 
difference  is  that  software  development  requires  no  production  phase, 
but  proceeds  directly  from  full-scale  development  to  deployment. 

The  concurrent  hardware  and  software  development  cycles  illustrated 
in  Figure  2-1  are  applicable  in  a general  sense  to  systems  requiring 
comparable  development  efforts  for  both.  In  addition,  computer  programs 
often  are  developed  for  studies,  concept  validation,  and  other  special 
circumstances  that  do  not  include  parallel  hardware  development.  Several 
software  development  life  cycles  therefore  may  occur  during  one  system 
development  life  cycle. 

The  general  tasks  required  for  software  development  after 
establishment  of  the  hardware  and  software  requirements  are  as  follows: 

a.  Preliminary  design, 

b.  Detailed  design, 

c.  Coding  and  unit  test, 

d.  Integration  and  test  (CPCI  tests  and  integrated 
system  testing),  and 

e.  Installation. 

Table  2-1  briefly  describes  these  tasks  and  relates  them  to  reviews, 
audits,  baselines,  and  primary  product  documents. 
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The  reviews  and  audits  shown  in  Table  2-1  and  Figure  2-1  are 
based  on  the  requirements  of  MIL-STD-1521A  (USAF)  except  for  the  TRR 
(Test  Readiness  Review),  a contractor  internal  review  that  ensures  that 
prerequisites  for  software  integration  and  system  testing  have  been  per- 
formed. Separate  reviews  and  audits  usually  are  conducted  for  the  hard- 
ware and  software  portions  of  a system  subsequent  to  SDR  (System  Design 
Review)  and  prior  to  the  integrated  system  FCA  (Functional  Configuration 
Audit),  PCA  (Physical  Configuration  Audit),  and  FQR  (Formal  Qualification 
Review).  The  configuration  management  principles  of  MIL-STD-483  and 
the  specification  requirements  of  MIL-STD-490  also  are  implied  in  Table 
2-1  and  Figure  2-1. 

For  additional  information  on  the  software  development  environment, 
see  AFR  800-14,  Vol.  II,  and  the  guidebook  in  this  series  entitled,  "SAE 
Guidebooks  — Application  and  Use." 
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3.  RSS  SYSTEM 


The  RSS  system  is  massive  and  complicated,  and  is  often 
cumbersome  because  it  was  not  designed  as  a system  originally  and  has 
never  been  maintained  as  a system.  Nevertheless,  its  parts  fit  together 
in  a loose  structure  possessing  some  logical  relationships.  This  section 
describes  the  RSS  structure  and  points  out  those  parts  that  are  most 
important  to  the  AF  Program  Office  and  engineering  personnel  involved 
in  airborne  system  software  acquisition. 

3 . 1 RSS  CATEGORIES  AND  TYPES 

RSS  that  have  a bearing  on  procurements  within  DOD  may  be 
divided  into  two  categories: 

a.  Internal  Documents.  These  are  RSS  applicable  internally 
to  the  Government  (directives,  regulations,  etc.)  or 
internally  to  a contractor  (procedures,  internal 
reports,  etc.). 

b.  Compliance  Documents.  These  are  RSS  that  are  used  to 
impose  contract  requirements  on  a contractor  (specifications 
and  standards). 

A further  breakdown  of  the  RSS  within  these  two  categories  is  shown 
in  Table  3-1,  together  with  the  RSS  documents  that  govern  the  format 
and  content  of  each  RSS  type  and  the  rules  for  referencing  compliance 
documents  in  procurement  contracts.  The  purposes  of  most  of  the 
document  types  in  the  RSS  system  are  described  in  Table  3-2. 

Note  in  these  two  tables  that  the  RSS  system  employs  two  general 
kinds  of  "specifications:"  (a)  the  military.  Federal,  and  DOD  industry 
adopted  specifications  that  contain  general  requirements  (Type  9)  or 
detail  requirements  (Type  8)  applicable  to  more  than  one  procurement 
program  and  (b)  the  program -peculiar  specifications  (Types  5,  6,  and  7) 
that  define  unique  procurement  items. 
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Table  2-1.  Major  Component 


System/Software  i 
Life  Cycle 


System 

Primary  Software  Product  Document* 

Acquisition 

Life  Cycle  Phase 

Development  Tasks 

Reviews  and  Audita 

Baselines 

Document  Type 

Time 
of  Issue 

— 

Originator 

CONCEPTUAL  PHASE 

Purpose:  To  define 
overall  mission  and 
system  requirements. 

Preliminary  statement 
of  software  require- 
ments, if  available. 

1.  System  Requirements 
Review  (SRR)* 

2.  DSARC  I 
(Program  Decision) 

Functional  Baseline 
(configuration  con- 
trol of  Preliminary 
System  Spec  or  Pre- 
liminary System 
Segment  Spec) 

Preliminary  System 

Spec  (or  Preliminary 
System  Segment  Spec) 

At  SRR 

Program  Office 
or  conceptual 
phase 
cont  ractor 

VALIDATION  PHASE 

Purpose:  To  validate 
system  concepts  and 
establish  the  functional 
requirements  for  major 
end  items  of  the  system. 

Major  system  charac- 
teristics are  refined 
through  studies,  sys- 
tem engineering,  and 
preliminary  equipment 
and  computer  program 
development,  test, 
and  evaluation. 

1.  System  Design 

Review  (SDR) 

2.  DSARC  II 
(Ratification 

Decision) 

Allocated  Baseline 
(configuration  con- 
trol of  System  Spec 
or  System  Segment 
Spec  and  usually  of 
CPCI  Development 
Specs) 

1.  Final  System  Spec 
(or  Final  System 
Segment  Spec) 

2.  Preliminary  CPCI 
Development  Specs 

At  SDR 

Validation 
phase 
cont  ractor 

— 

FULL-SCALE 
ENGINEERING 
DEVELOPMENT  PHASE 

Purpose:  To  design. 

1.  Preliminary  Design. 
Definition  of  the  CPCIs 
in  terms  of  functions, 
external  and  internal 
interfaces,  storage 
allocation,  operating 
sequences,  and  data 

Preliminary  Design 
Review  (PDR) 

1.  Final  CPCI 
Development  Specs 

2.  Preliminary  CPCI 
Code-To  Product 

At  PDR 

Software 
development 
cont  ractor 

build,  and  test  system 
end  items;  to  integrate 
end  *tems  into  a com- 
plete system;  and  to 
test  system  under  as 
nearly  operational  con- 
ditions as  possible. 

Specs 

base  design. 

2.  Detailed  Design. 
Definition  of  CPCI 
structure,  interface 
logic,  and  data  base  to 
point  where  coding  can 
begin. 

Critical  Design  Review 
(CDR ) 

“ - 

Final  CPCI  Code-To 
Product  Specs 

At  CDR 

Software 
development 
cont  ractor 

3.  Coding  and  Unit  Test. 
Routines  and  data  files 
are  coded,  debugged 
(will  compile),  and 
checked  out  (will  pro- 
duce correct  results 
from  predefined  inputs). 

Test  Readiness  Review 
(TRR,  a contractor 
internal  review) 

4.  Integration  and  Test 

a.  CPCI  Tests.  CPCIs 
are  tested  together  in 
increasingly  larger 
combinations  until  all 
CPCIs  developed  by  the 
same  contractor  are 
functioning  together 
correctly. 

1.  Functional  Configura- 
tion Audit  (FCA) 

2.  Physical  Configura- 
tion Audit  (PCA) 

Preliminary  Product 
Baseline  (configura- 
tion control  of  Sys- 
tem Spec  or  System 
Segment  Spec,  of 
CPCI  and  Cl  Devel- 
opment and  Product 
Specs,  and  of  CPCIs 
and  Cls  themselves) 

CPCI  As-Coded 

Product  Specs 

At  PCA 

Software 

development 

contractor 

b.  Integrated  System 
Testing.  All  CPCIs  and 

1.  Same  as  preceding 
(FCA,  PCA),  as 

Product  Baseline 
(configuration  con- 

1.  User  Manual 

2.  Positional 

Handbooks 

3.  Computer  Program- 
ming Manual 

At  Product 
Baseline 

Software  or 
hardware  dev* 

hardware  Cls  of  the  sys- 
tem are  tested  together 
to  verify  that  the  system 
meets  the  requirements 
of  the  system  spec . 

required 

2.  Formal  Qualification 
Review  (FQR) 

3.  DSARC  III 
(Product  Decision) 

trol  of  same  items 
as  for  Preliminary 
Product  Baseline, 
but  updated) 

opment  cont  rap 
tor  or  system 
integration  cod 
tractor,  as 
appropriate 

PRODUCTION/ 
DEPLOYMENT  AND 
OPERATION/ 
MAINTENANCE  PHASES 

Installation,  mainte- 
nance, and  modifica- 
tion, as  required. 

-- 

None  (usually  con- 
tinuing configuration 
control  of  specs  and 
products) 

-- 

mm 

Purpose:  To  field  system 
to  operational  sites  and  in- 
stall and  test  them,  then to 
operate  and  maintain  them, 

■ — 

*SRRi  normally  are  conducted  during  the  conceptual  phase  or  validation  phase,  but  also  may  be  conducted  any  other  time. 

Example  documentation  requirements  for  software  acquisition  are  listed  in  Table  5-2  and  shown  in  life  cycle  context  in  Figure  5-1 
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Table  2-1.  Major  Components  of  Typical 
System/Software  Acquisition 
Life  Cycle 


r 

Primary  Software  Product  Documents** 

Development  Tasks 

Reviews  and  Audits 

Baselines 

Document  Type 

Time 
of  Issue 

Originator 

Governing 

RSS 

t 

Preliminary  statement 
of  software  require- 
ments, if  available. 

1.  System  Requirements 
Review  (SRR)* 

2.  DSARC  I 
(Program  Decision) 

Functional  Baseline 
(configuration  con- 
trol of  Preliminary 
System  Spec  or  Pre- 
liminary System 
Segment  Spec) 

Preliminary  System 

Spec  (or  Preliminary 
System  Segment  Spec) 

At  SRR 

Program  Office 
or  conceptual 
phase 
contractor 

MIL -STD- 490, 
MIL -STD- 483, 
and  appropriate 
DIDs. 

E 

L 

Major  system  charac- 
teristics are  refined 
through  studies,  sys- 
tem engineering,  and 
preliminary  equipment 
and  computer  program 
development,  test, 
and  evaluation. 

1.  System  Design 

Review  (SDR) 

2.  DSARC  II 
(Ratification 

Decision) 

Allocated  Baseline 
(configuration  con- 
trol of  System  Spec 
or  System  Segment 
Spec  and  usually  of 
CPCI  Development 
Specs) 

1.  Final  System  Spec 
(or  Rnal  System 
Segment  Spec) 

2.  Preliminary  CPCI 
Development  Specs 

At  SDR 

Validation 
phase 
cont ractor 

MIL-STD-490. 
MIL-STD-483, 
and  appropriate 
DIDs. 

ASE 

b 

1- 

1.  Preliminary  Design. 
Definition  of  the  CPCIs 
in  terms  of  functions, 
external  and  internal 
interfaces,  storage 
allocation,  operating 
sequences,  and  data 
base  design. 

Preliminary  Design 
Review  (PDR) 

1.  Final  CPCI 
Development  Specs 

2.  Preliminary  CPCI 
Code- To  Product 
Specs 

At  PDR 

Software 
development 
cont ractor 

MIL-STD-490, 
MIL-STD-483. 
and  appropriate 
DIDs. 

2.  Detailed  Design. 
Definition  of  CPCI 
structure,  interface 
logic,  and  data  base  to 
point  where  coding  can 
begin. 

Critical  Design  Review 
(CDR) 

Final  CPCI  Code-To 
Product  Specs 

At  CDR 

Software 

development 

contractor 

MIL-STD-490. 
MIL-STD-483, 
and  appropriate 
DIDs. 

3.  Coding  and  Unit  Test. 
Routines  and  data  files 
are  coded,  debugged 
(will  compile),  and 
checked  out  (will  pro- 
duce correct  results 
from  predefined  inputs). 

Test  Readiness  Review 
(TRR,  a contractor 
internal  review) 

i 

4.  Integration  and  Test 

».  CPCI  Teat,.  CPCIa 
are  tested  together  in 
increasingly  larger 
combinations  until  all 
CPCIs  developed  by  the 
same  contractor  are 
functioning  together 
correctly. 

1.  Functional  Configura- 
tion Audit  (FCA) 

2.  Physical  Configura- 
tion Audit  (PCA) 

Preliminary  Product 
Baseline  (configura- 
tion control  of  Sys- 
tem Spec  or  System 
Segment  Spec,  of 
CPCI  and  Cl  Devel- 
opment and  Product 
Specs,  and  ofCPCIs 
and  CIs  themselves) 

CPCI  As-Coded 

Product  Specs 

At  PCA 

Software 

development 

contractor 

MIL-STD-490. 
MIL-STD-483, 
and  appropriate 
DIDs. 

b.  Integrated  System 
Testing.  All  CPCIs  and 

1.  Same  as  preceding 
(FCA.  PCA).  as 

Product  Baseline 
(configuration  con- 

1.  User  Manual 

2.  Positional 

Handbooks 

3.  Computer  Program- 
ming Manual 

At  Product 
Baseline 

Software  or 
hardware  devel- 

Appropriate 

DIDs. 

hardware  CIs  of  the  sys- 
tem are  tested  together 
to  verify  that  the  system 
meets  the  requirements 
of  the  system  spec . 

required 

2.  Formal  Qualification 
Review  (FQR) 

i.  DSARC  III 

(Product  Decision) 

trol  of  same  items 
as  for  Preliminary 
Product  Baseline, 
but  updated) 

opment  contrac- 
tor or  system 
integration  con- 
tractor, as 
appropriate 

L 

Item 
d in- 
to to 

kem. 

Installation,  mainte- 
nance, and  modifica- 
tion, as  required. 

None  (usually  con- 
tinuing configuration 
control  of  specs  and 
products) 

|«MMlucte(l  during  the  conceptual  phase  or  validation  phase,  but  also  may  be  conducted  any  other  time. 

requirements  for  software  acquisition  are  listed  in  Table  5-2  and  shown  in  Ilfs  cycle  content  in  Figure  5-1. 


I.  INTERNAL  DOCUMENTS 


Governing  RSS* 


GOVERNMENT  INTERNAL  DOCUMENTS 


Directive  Types 


DOD  Directives  (DODD) 
DOD  Instruction  (DODI) 
Regulation 
Manual 

Operating  Instruction 
Publishing  Bulletin 
Supplement 
Technical  Orders 


Informative  Types 


Pamphlet 
Visual  Aid 

Base  or  Headquarters  Official  Bulletin 
Staff  Digest 


Special  Types 


Design  Handbook 
Guidebook 


CONTRACTOR  INTERNAL  DOCUMENTS 


Contractor  Internal  Types 


Design  Handbook  and  Manual 
Report 

Contractor  Standard 

Contractor  Procedure  and  Process  Document 


For  format  and  content. 


Contractor 
Documentation 
Policies  and 
Standards 
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Ig  RSS* 


Rules  for  Compliance 
References 


In  general,  internal 
documents  (Types  1 
through  4)  should  not 
not  be  listed  as 
compliance 
references  in 
compliance 
documents  (Types  5 
through  i 1 ) 


II.  COMPLIANCE  DOCUMENTS 


C.  PROGRAM- PECULIAR  COMPLIANCE 
DOCUMENTS 


5.  System  Specification 


6.  System  Segment  (or  Subsystem)  Specification 


7.  Cl  (and  CPCI)  Specification 


7a.  Development  Specification 
7b.  Product  Specification 


D.  GENERAL  COMPLIANCE  DOCUMENTS 


8.  Detail  Specifications  (Military,  Federal,  and  DOD 
Adopted  Industry) 


9.  General  Specifications  (Military,  Federal,  and 
DOD  Adopted  Industry) 


10.  Handbooks  (Military,  Federal,  and  DOD 
Adopted  Industry 


11.  Standards  (Military,  Federal,  and  DOD  Adopted 
Industry 


Governing  RSS* 


MIL-STD-490 

and 

MIL-STD-483 


MIL-STD-961 


MIL-STD-962 


lor 

station 

and 


Table  3-1.  RSS  Types 


II.  COMPLIANCE  DOCUMENTS 

Governing  RSS* 

Rules  for  Compliance 
References 

C. 

PROGRAM-PECULIAR  COMPLIANCE 

DOCUMENTS 

MIL-STD-490 

and 

In  general,  a 
compliance  document 

5. 

System  Specification 

MIL-STD-483 

(Types  5 through  11) 

6. 

System  Segment  (or  Subsystem)  Specification 

should  contain 

compliance 
references  only  to 

7. 

Cl  (and  CPC I)  Specification 

7a. 

Development  Specification 

documents  below  it 

7b. 

Product  Specification 

in  this  chart. 

D. 

GENERAL  COMPLIANCE  DOCUMENTS 

Prohibited 

references  include 

the  following: 

• A system  specifi- 
cation should  not 
reference  a DOD 
directive  or  an 

AF  regulation 

8. 

Detail  Specifications  (Military,  Federal,  and  DOD 
Adopted  Industry) 

MIL-STD-961 

9. 

General  Specifications  (Military,  Federal,  and 

DOD  Adopted  Industry) 

10. 

Handbooks  (Military,  Federal,  and  DOD 

Adopted  Industry 

MIL-STD-962 

11. 

Standards  (Military,  Federal,  and  DOD  Adopted 
Industry 

W /V  V>  JL  X b ULC  ill 

cation  should  not 
reference  a 
system  segment 
specification  or  a 
system 
specification 

• A general 
specification 
should  not 
reference  a detail 
specification 

• A standard  should 
not  reference  a 
handbook  or  a 
specification 

Table  3-2.  De» 


1 . Directive  Tv 


I.  INTERNAL  DOCUMENTS 


A.  GOVERNMENT  INTERNAL  DOCUMENTS 


POD  Directive  a (DODD).  DOI)  directives  provide  policy 
guidance  to  the  A»r  Force,  Army,  Navy,  and  other  DOD 
agencies.  They  are  implemented  in  the  Air  Force  through 
the  AF  Standard  Publication  System. 


lb.  DOP  Instruction  (DOI)I).  DOD  instructions  describe  how 


a DOD  directive  policy  is  implemented.  DODIs  a re  implement- 
ed in  the  Air  Force  through  the  AF  Standard  Publication  System. 

lc.  Regulation.  Regulations  are  policy  statements  of  DOD, 
Air  Force,  or  other  DOD  components. 

ld.  Manual.  Manuals  implement  regulations  by  defining 
policies,  concepts,  techniques,  procedures,  and 
responsibilities. 


lc.  Operating  Instruction.  Operating  instructions  announce 
policy  and  prescribe  procedures  within  a headquarters 
(headquarters  operating  procedures  or  HOI),  within  an 
organizational  element  (e.  g.  , branch  operating  instruction, 
or  BOI),  or  within  a maintenance  functional  area  (mainte- 
nance operating  instruction,  or  MOI). 


If.  Publishing  Bulletin.  Publishing  bulletins  direct  and 
inform  personnel  of  the  AF  publications  distribution 
system  operating  under  AFM  7-1. 


lg.  Supplement.  Supplements  are  issued  at  the  command 
level  to  supplement  a basic  publ ication  ( regulation,  manual, 
or  instruction)  of  a higher  headquarters.  They  are  not  sub- 
stitutes for  new  publications  and  are  not  used  to  correct  or 
alter  existing  publications. 

lh.  Technical  Orders.  Technical  Orders  are  instructions 
for  operating  anc  maintaining  equipment  or  performing 
other  tasks  that  require  a standard  procedure. 


. Informative  Types 


2*.  Pamphlet.  Pamphlets  are  nondirective,  informal 
informational  publications. 

2b.  V isual  Aid.  Visual  aids  are  permanent  or  temporary 
charts,  posters,  or  other  graphic  illustrations  issued  for 
display. 

2c.  Base  or  Headquarters  Official  Bulletin.  These  bulle- 
tins contain  temporary  announcements,  notices,  and 
instructions. 


2d.  Staff  Digest.  Staff  digests  contain  summaries  of  signi- 
ficant  staff  actions,  important  announcements,  and  special 
notices. 


3 . Spec  ial  1 3 


3a.  Design  Handbook.  Design  Handbooks  are  suggested 
practices  that  supplement  specifications  and  standards  by 
bringing  together  proceduial  and  technical  design  informa- 
tion in  the  form  >»f  general  design  and  engineering  data. 
Design  handbooks  are  not  directive  and  are  not  an  integral 
part  of  the  Defense  Standardization  Program. 

3b.  Guidebook.  Guidebooks  assist  the  Air  Force  or  other 
DOD  component  in  performing  management  activities. 


B.  CONTRACTOR  INTERNAL  DOCUMENTS 


Contractor  internal  documents  arc  normally  nondeliver- 
ablc  documents  that  contractors  employ  for  standardiza- 
tion, guidance,  instruction,  and  reporting  within  their  own 
organizations  during  the  planning  and  implementation  of  a 
Government  contract.  They  include: 


4a.  Design  Handbook  and  Manual 


4b.  Report 


4c.  Contractor  Standard 


4d.  Contractor  Procedure  and  Process  Document 
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II.  COMPLIANCE  DOCUME 


C.  PROGRAM-PECULIAR  COMPLIANCE 


5 . System  Specification 


The  system  specification  states  the  technical  and  mission  req 
allocates  requirements  to  segments,  subsystems,  configurati 
areas,  defines  the  interfaces  between  the  functional  areas,  ar 
requirements.  (The  system  specification  is  Type  A in  MIL-  SI 
in  MIL-STD-483,  Appendix  111.) 


System  Segment  (or  Subsystem)  Specification* 


A system  segment  is  a discrete  package  of  system  performand 
interfaces,  and  configuration  items  allocated  for  development  fl 
Government  organization  by  the  procuring  activity.  A system  ( 
when  a system  or  major  equipment  is  acquired  on  an  incremeq 
when  a segment  of  an  existing  system  requires  major  modified 
system  segment  specification  is  the  same  as  for  a system  sp«4 
MIL-STD-483).  When  coverage  is  limited  to  a single  prime  in 


development  specification  (Type  B1  in  MIL-STD-483)  is  adequd 
requires  the  latter  to  be  used  instead  of  a system  segment  ipsj 


. Cl  (and  CPC I)  Specification* 


Configuration  item  (Cl)  specifications  generally  are  prepared  ■ 
technical  characteristics  of  CIs  that  the  contractors  are  develq 
types  of  computer  program  configuration  item  (CPCI)  specified 

7a.  Development  Specification.  The  CPCI  development  specil 
MII.-STD-490  and  Part  I in  MIL-STD-48  3)  specifies  the  perfo^ 
requirements  of  a CPCI  clement.  It  describes  in  operational,] 
terms  all  requirements  necessary  to  design  the  CPCI  or  elema 
perfoi  juance  criteria. 

7b.  Product  Specification.  The  CPCI  product  specification  (*fl 
Part  II  in  MIL-STD-48  3)  specifics  the  detailed  design  of  a CPQ 
of  technical  descriptions,  flow  charts,  and  in  the  final  version. 
Prior  to  coding,  this  specification  defines  the  code-to-design; 
as-coded  design. 


D.  GENERAL  COMPLIANCE  DOC 


Detail  Specifications 


(Military,  Federal,  and  DOD  Adopted  Industry) 


9.  General  Specifications* 

(Military,  Federal,  and  DOD  Adopted  Industry) 

Military  Specifications  cover  items  or  services  that  are  intriflj 
are  commercial  items  with  features  that  meet  special  militarf 
commercial  items  with  no  present  or  known  potential  use  by  F 
the  military.  Federal  specifications,  which  are  issued  by  thai 
stration  (GSA),  cover  items  or  services  that  are  used  by,  or  I 
or  more  Federal  agencies,  at  least  one  of  which  is  an  agency  i 
cations  may  be  either  detail  or  general: 

a.  A detail  specification  covers  all  requirements  for  one  or  ■ 
to  a level  of  detail  that  eliminates  the  need  for  preparation  of  j 
specification.  A detail  specification  also  may  take  the  form  oi 
refers  to  a general  specification  for  requirements  common  to] 

b.  A general  specification  covers  requirements  common  to  aj 
systems,  or  other  products,  or  to  a group  of  services  or  matj 


10.  Hand  books  (Military,  Federal,  and  DOD  Adopted  Indust 

Handbooks  present  general  information,  procedural  or  technii 
mation  that  is  related  to  the  Defense  Standarization  Program 
design,  engineering,  production  procurement,  or  supply  ma 
preparation  of  specifications  and  standards.  Military  handb 
reference  material  that  will  serve  the  Standardization  Progra 
standardization  references  is  optional,  and  not  all  handbook*  ' 
references. 


11.  Standards  (Military,  Federal,  and  DOD  Adopted  Indust 

Standards  are  publications  that  establish  engineering  and  tecl 
for  items,  materials,  processes,  methods,  designs,  and  eng 
in  procurement  through  the  medium  of  specifications  and  ara 
features  of  an  item.  Standards  are  invoked  at  the  discretion 
accordance  with  AFR  73-1,  * Defense  Standardization  Prograi 


Specifications  describe  the  essential  technical  requiremen 
to  be  procured,  including  the  procedures  for  determining  3 
met. 
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Table  3-2.  Description  of  RSS  Types 


INTERNAL  DOCUMENTS 
RNMENT  INTERNAL  DOCUMENTS 


)S  (DODD).  1)01)  directives  provide  policy 
r Force,  Army,  Navy,  and  other  DOD 
-e  implemented  in  the  Air  Force  through 
tiblicat  on  System. 

on  (DODD.  1)00  instructions  describe  how 
liicy  is  implemented.  DODls  a re  implement- 
through  the  AF  Standard  Publication  System. 

tegulations  are  policy  statements  of  DOD, 
er  OOO  components. 

lals  implement  regulations  by  defining 
, techniques,  procedures,  and 

truction.  Operating  instructions  announce 
be  procedures  within  a headquarters 
rating  procedures  or  HOI),  within  an 
hnent  (e.  g. , branch  operating  instruction, 
i a maintenance  functional  area  (mainte- 
kstruction,  or  MOI). 

>1  let  in.  Publishing  bulletins  direct  and 
oi  the  AF  publications  distribution 
und  e r A F'  M 7 - 1 . 

Supplements  are  issued  at  the  command 
Bt  a basic  publ ication  ( regulation,  manual, 
fa  higher  headquarters.  They  are  not  sub- 
Kibl ications  and  are  not  used  to  correct  or 
|licat  ions. 

piers.  Technical  Orders  are  instructions 
(maintaining  equipment  or  performing 
Require  a standard  procedure. 


bmphlets  are  nondirective,  informal 
ications. 

K 

isual  aids  are  permanent  or  temporary 
other  graphic  illustrations  issued  for 

uarters  Official  Bulletin.  These  bul'e- 
rary  announcements,  notices,  and 

I 

[Staff  digests  contain  summaries  of  sigm- 
ii,  important  announcements,  and  special 


ok.  Design  Handbooks  are  suggested 
lement  specifications  and  standards  b/ 
procedural  and  technical  design  informa - 
; general  design  and  engineering  data, 
are  not  directive  and  are  not  an  integral 
le  Standardization  Program. 

foiidcbooks  assist  the  Air  Force  or  other 
I performing  management  activities. 
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locuments  are  normally  nondeliver- 
contractors  employ  for  standardiza- 
tion, and  reporting  within  their  own 
the  planning  and  implementation  of  a 
. They  include: 

ok  and  Manual 


irocedure  and  Proceaa  Document 


II.  COMPLIANCE  DOCUMENTS 
C.  PROGRAM-PECULIAR  COMPLIANCE  DOCUMENTS 

5 . System  Specification* 

The  system  specification  states  the  technical  and  mission  requirements  for  the  system, 
allocates  requirements  to  segments , subsystems,  configuration  items,  or  other  functional 
areas,  defines  the  interfaces  between  the  functional  areas,  and  specifies  system  level  test 
requirements.  (The  system  specification  is  Type  A in  MIL-STD-490  and  is  also  discussed 
in  MIL-STD-483,  Appendix  III.) 

6 . System  Segment  (or  Subsystem)  Specification  * 

A system  segment  is  a discrete  package  of  system  performance  requirements,  functional 
interfaces,  and  configuration  items  allocated  for  development  to  one  contractor  or  one 
Government  organization  by  the  procuring  activity.  A system  segment  specification  is  used 
when  a system  or  major  equipment  is  acquired  on  an  incremental  or  evolutionary  basis  or 
when  a segment  of  an  existing  system  requires  major  modification.  The  format  for  a 
system  segment  specification  is  the  same  as  for  a system  specification  (Appendix  III  in 
MIL-STD-483).  When  coverage  is  limited  to  a single  prime  item  and  a prime  item 
development  specification  (Type  HI  in  MIL-STD-483)  is  adequate,  MIL-STD-483 
requires  the  latter  to  be  used  instead  of  a system  segment  specification. 

7.  Cl  (and  CPCI)  Specification* 

Configuration  item  (Cl)  specifications  generally  are  prepared  by  contractors  tc  describe  the 
technical  characteristics  of  CIs  that  the  contractors  are  developing.  For  software,  two 
types  of  computer  program  configuration  item  (CPCI)  specifications  are  applicable. 

7a.  Development  Specification.  The  CPCI  development  specification  (Type  B5  in 
MIL-STD-490  and  Part  I in  MIL-STD-483)  specifies  the  performance,  design,  and  test 
requirements  of  a CPCI  clement.  It  describes  in  operational,  functional,  or  mathematical 
terms  all  requirements  necessary  to  design  the  CPCI  or  element  and  to  test  it  against 
performance  criteria. 

7b.  Product  Specification.  The  CPCI  product  specul  ation  (Type  C5  in  MIL-STD-490  and 
Part  II  in  MIL-STD-48  3)  specifics  the  detailed  design  of  a CPCI  or  CPCI  element  in  terms 
of  technical  descriptions,  flow  charts,  and  in  the  final  version,  computer  program  listings. 
Prior  to  coding,  this  specification  defines  the  code-to-design;  after  coding,  it  defines  the 
as-coded  design. 

D.  GENERAL  COMPLIANCE  DOCUMENTS 

8.  Detail  Specifications  * 

(Military,  Federal,  and  DOD  Adopted  Industry) 

9.  General  Specifications  * 

(Military,  Federal,  and  DOD  Adopted  Industry) 

Military  Specifications  rover  items  or  services  that  are  intrinsically  military  in  character, 
are  commercial  items  with  features  that  meet  special  military  requirements,  or  are 
commerc  ial  items  with  no  present  or  known  potential  use  by  Federal  agencies  other  than 
the  military.  Federal  specifications,  which  are  issued  by  the  General  Services  Admini- 
stration (GSA),  cover  items  or  services  that  are  used  by,  or  have  a potential  use  by,  two 
or  more  Federal  agencies,  at  least  one  of  which  is  an  agency  other  than  DOD.  Specifi- 
cations may  be  either  detail  or  general: 

a.  A detail  specification  covers  all  requirements  for  one  or  more  types  of  items  or  services, 
to  a level  of  detail  that  eliminates  the  need  for  preparation  of  or  reference  to  a genera) 
specification.  A detail  specification  also  may  take  the  form  of  a specification  sheet  that 
refers  to  a general  specification  for  requirements  common  to  the  family  of  items  or  services. 

b.  A general  specification  covers  requirements  common  to  a group  of  weapor  systems,  sub- 
systems, or  other  products,  or  to  a group  of  services  or  materials. 

10.  Hand  books  (Military,  Federal,  and  DOD  Adopted  Industry) 

Handbooks  present  general  information,  procedural  or  technical  use  data,  or  design  infor- 
mation that  is  related  to  the  Defense  Standari/ation  Program  and  will  be  used  in  equipment, 
design,  engineering,  production  procurement,  or  supply  management  operations,  or  for 
preparation  of  specifications  and  standards.  Military  handbooks  also  provide  industry  with 
reference  material  that  will  serve  the  Standardization  Program.  The  use  of  handbooks  as 
standardization  references  is  optional,  and  not  all  handbooks  are  appropriate  for  such 
references. 

11.  Standards  (Military,  Federal,  and  DOD  Adopted  Industry) 

Standards  are  publications  that  establish  engineering  and  technical  limitations  and  applications 
for  items,  materials,  processes,  methods,  designs,  and  engineering  practices.  They  function 
in  procurement  through  the  medium  of  specifications  and  are  used  to  standardise  one  or  more 
features  of  an  item.  Standards  are  invoked  at  the  discretion  of  the  procuring  agency,  in 
accordance  with  AFR  73-1,  "Defense  Standardization  Program." 

$ 

Specifications  describe  the  essential  technical  requirements  of  items,  materials,  or  services 
to  be  procured,  including  the  procedures  for  determining  whether  the  requirements  havs  bsan 
met. 
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The  most  important  RSS  for  acquisition  of  software  for  airborne 
systems  are  listed  in  Table  3-3  and  are  summarized  in  Appendix  A. 
Additional  RSS  that  have  some  relevance  to  software  acquisition  are 
listed  in  Appendix  B. 

The  Air  Force,  major  commands,  and  field  organizations  are 
required  to  review  the  need  for,  and  the  content  of,  each  document  issued 
by  the  organization  and  to  periodically  issue  indexes  of  all  current 
standard  documents.  Table  3-4  lists  the  most  important  indexes  and 
several  other  documents  concerning  the  generation  and  use  of  RSS. 

The  numbering  conventions  for  identification  of  major  kinds  of 
RSS  are  shown  in  Table  3-5. 

3.2  IMPORTANCE  OF  AF  800  SERIES  DOCUMENTS 

The  most  important  regulation  concerning  the  acquisition  of  soft- 
ware for  airborne  systems  is  AFR  800-14,  Volume  II,  entitled  "Acquisition 
and  Support  of  Computer  Resources  in  Systems.  " This  regulation  and 
its  companion  Volume  I (with  AFSC  Supplement  1)  provide  guidance  for 
the  proper  planning,  development,  acquisition,  employment,  and  support 
of  computer  hardware  and  software  resources  for  major  defense  systems. 
Computer  resources  are  the  only  commonly  used  components  of  Air 
Force  systems  whose  acquisition  and  support  have  been  treated  in  a 
separate  regulation.  One  reason  is  that  computer  resources,  particularly 
software,  are  sometimes  minor  parts  of  a total  system  in  terms  of 
resources  expended  and  therefore  have  at  times  received  inadequate 
management  attention.  Moreover,  computer  technology  is  a new  and 
different  technology  in  many  respects  and  often  is  the  critical  path  item 
in  system  procurements. 

Volume  I of  AFR  800-14  establishes  the  basic  policies  for  managing 
the  acquisition  and  support  of  computer  resources,  and  Volume  II  is  a 
comprehensive  presentation  of  the  concepts  and  procedures  required  for 
implementing  these  policies.  Volume  II  contains  sections  on  management 
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Table  3-3.  List  of  Key  RSS 


Appendix  A 

Pa  rag raph 

Number 

RSS  Category  and  Type 

RSS  No. 

RSS  Title 

A.  1 

INTF.RNA  1.  DOCUMENTS 

A.  1.  1 

DOD  Documents 

DOD  4120.  1-M 

V 

Stands  rdization  of  Policies.  Procedures,  and  Instructions 

DODD  5000.  1 

Major  System  Acquisitions 

DODD  5000.2 

Major  System  Acquisition  Process 

DODD  5000.  3 

Test  and  Evaluation 

DODD  5000.  19 

Policies  for  the  Management  and  Control  of  DOD  Information 

Requirements 

DOD  5000.  19-1.,  Volume  II 

Acquisition  Management  Systems  and  Data  Requirements 

Control  List  (AMSDL) 

DODD  5000.29 

Management  of  Computer  Resources  in  Major  Defense  Systems 

DODD  5000.31 

Interim  List  of  DOD  Approved  High  Order  Programming 

Languages  (HOD 

DOD  I 5010.  12 

Management  of  Technical  Data 

DODD  5010.  19 

Confipural  ion  Management 

DOD  7935.  1 -S 

Automated  Data  Systems  Documentation  Standards 

A . 1 . 2 

AF  Regulations 

AFR  65-3 

Configuration  Management 

AFR  71  1 

Defense  Standardization  Program  (DSP) 

AFR  74-1 

Quality  Assurance  Program 

AFR  80  14 

Research  and  Development  Test  and  Fvaluation 

AFR  300  2 

Management  of  the  i'SAP'  Automatic  Data  Processing  Program 

AFR  800-2  (Cl) 

Acquisition  Management  - Program  Management 

AFR  800  3 

Engineering  lor  Defense  Systems 

AFR  800  4 

1 ransfer  of  Program  Management  Responsibility 

AFR  800-11 

Life  Cycle  Costing  ( L.CC  1 

AFP.  800  14.  Volume  I 

Management  of  Computer  Resources  in  Systems 

AFR  800  14.  Volume  II 

Acquisition  and  Support  Procedures  for  Computer  Resources  in  Systems 

AFR  800  19 

System  or  Equipment  Turnover 

A.  i.  3 

AFSC  Pamphlets 

AFSC.P  800  -7 

Configuration  Management 

A.  t .4 

SAMSO  Pamphlels/Regulations 

SAMSOP  74-2 

Contractor  Software  Quality  Assurance  Flvaluatton  Guide 

SAMSOR  70-2 

Request  for  Proposal  Policy 

A. 1.5 

AFSC  Design  Handbooks 

AFSC  DM  4-2 

Electronic  Systems  Test  and  Evaluation 

A . 1 . 6 

Navy  Instructions 

NAVMATINST  4130. 2A 

Configuration  Management  of  Computer  Software  Associated  with 

Tactical  Digital  Systems  and  other  Technical  Computer  Systems 

SECNAVINST  3560.  1 

Tactical  Digital  Systems  Documentation  Standards 

A.  1.7 

Army  (DOD)  Regulations 

AR  70-37 

C onfiguration  Management 

A.1  .1 

Technical  Orders 

TO-00-5-2 

Technical  Order  Distribution  System 

A. 2 

c OMPUANCE  DOCUMENTS 

A. 2.1 

Military  Specifications 

MII.-Q  -9858A 

Quality  Program  Requirements 

MI1.-S-52779  (AD) 

Softwa  re  Quality  Assurance  Procram  Requirements 

MILS  83490 

Specifications,  Types  and  Forms 

A.  2.  2 

Military  Standards 

M1I.-STD  130E 

Identification  Marking  of  U.S.  Military  Property 

MIL-STD-480 

Configuration  Control  - Engineering  Changes.  Deviations  and  Waivers 

MIL-STD  481  A 

Configuration  Control  - Pngineering  Changes.  Deviations  and 

Waivers  (Short  Form) 

MIL  -STD  -482  a 

Configuration  Status  Accounting  Data  Flemcnts  and  Related  Feature* 

MIL-STD -483  (USAF) 

Configura:  on  Management  Practices  tor  Systems.  Equipment, 

Munitions  and  Computer  Programs 

MIL-STD  -490 

Specification  Practices 

MIL-STD-499A 

Engineering  Management 

MIL-STD  881  A 

Work  Breakdown  Structures  for  Defense  Material  Items 

MIL-STD- 1 52l A (USAF) 

Technical  Reviews  and  Audits  for  Systems.  Equipments,  and 

Computer  Programs 

MIL-STD -1  588  (USAF) 

JOVIAL  (J  3) 

MIL-STD- 1 589  (USAF) 

JOVIAL  (173/1) 

MIL-  STD  - 1 679  (Navy)  Draft 

Tactical  Software  Development 

a.  a.  j 

SAM  SO  Standards 

SAMSO  F.xhibit  73-3  (Considered  a 
standard  by  SAMSO) 

Standard  F'ngmeering  Practices  for  Computer  Software  Design  and 
Development 

SAMSO -ST  D 73-513 

Quality  Assurance  Requirements  for  Space  and  Missile  Systems 

- # 
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Table  3-4.  List  of  Indexes  and  General  RSS  Publications 


Document  Number 


AFR  0-1 


AFR  0-2 


AFR  0-4 


AFR  0-15 


AFSCM/AFLCM  81-1 
MIL-STD-143B 


Document  Title 


Guide  to  Indexes,  Catalogs,  and  Lists  of 
Departmental  Publications 

Numerical  Index  of  Standard  Publications 
and  Recurring  Periodicals 

Department  of  Defense,  Joint  Chiefs  of 
Staff,  Interservice  Publications,  and  Air 
Force  Acquisition  Documents 

Defense  Intelligence  Agency  (DIA)  and 
Specialized  USAF  Intelligence  Publications 

Air  Force  Publications  Management  Progra 

International  Military  Standardization 
Programs  (AFSC  Supplement  26  October 
1967) 

Numerical  Index  of  AFSC  Publications 

Specifications  and  Standards  Manual 

Order  of  Precedence  for  the  Selection  of 
Standards  and  Specifications 
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Table  3-5.  RSS  Identification  Number  Conventions 


Document  Type 

Document  Subtype 

Format  of 
Document  Number  * 

Directive! 

DOD  Directive* 

DODD  1111.1 

Instruction* 

DOD  Instruction* 

DODI  1111.1 

Regulation* 

DOD  Regulation* 

Air  Force  Regulation* 

Air  Force  Systems  Command  Regulation* 

DOD  1111. 1-R 

AFR  11-1 

AFSCR  11  I 

Manual* 

Department  of  Defense  Manual* 

Air  Force  Manual* 

Air  Force  System*  Command  Manuals 

DOD  1111. 1-M 

AFM  11-1 

AFSCM  11-1 

Technical  Order* 

USAF  Technical  Orders 

TO  11-1-1 

Pamphlet* 

Air  Force  Pamphlet* 

Air  Force  System*  Command  Pamphlet* 

AFP  11-1 

AFSCP  11-1 

Bulletin* 

USAF  Specification  Bulletin 

AF/Navy  Aeronautical  Bulletin 

USAF  Spec  Bui  111 

ANA  Bui  111 

Design  Handbook* 

AFSC  Design  Handbook* 

DH  1-1 

Specification* 

Military  Specification* 

Federal  Specifications 

Aerospace  Material  Specifications 

MIL-S-1111 

FED  Spec  11-1-111 

AMS  111 

Handbook* 

Department  of  Defense  Handbooks 

Military  Handbooks 

Federal  Handbooks 

DOD  1111.1-H 

MIL-HDBK-111 

Hll  (year) 

Standard* 

Military  Standard  (book  form) 

Military  Standard  (sheet  form) 

AF/Navy  Aeronautical  Standards 

AF/Navy  Aeronautical  Design  Standard 
Federal  Standards 

National  Airspace  Standards  Institute 

American  National  Standards  Institute 

Federal  Information  Processing  Standards 

MIL-STD-111 

MS  11111 

AN  1111 

AND  1111 

FED-STD-111 

NAS  1111 

ANSI  X3.ll  year 

FIPS  PUB  11 

*The  digit  "1"  in  that*  document  number*  represent*  any  digit. 


directives  and  plans,  system  engineering,  software  testing,  configuration 
management,  software  documentation,  contract  preparation,  turnover 
and  transfer,  and  deployment. 

Four  major  computer  resource  directives  and  plans  are  defined 
in  AFR  800-14,  Volume  II: 

a.  Program  Management  Directive  (PMD).  "The  official 
HQ  USAF  management  directive  used  to  provide  direction 
to  the  implementing  and  participating  commands  and 
satisfy  documentation  requirements.  It  will  be  used  during 
the  entire  acquisition  cycle  to  state  requirements  and 
request  studies  as  well  as  initiate,  approve,  change, 
transition,  modify  or  terminate  programs.  The  content 

of  the  PMD,  including  the  required  HQ  USAF  review 
and  approval  actions,  is  tailored  to  the  needs  of  each 
individual  program.  " (Definition  from  AFR  800-2, 

Attachment  3,  16  March  1972.) 

b.  Program  Management  Plan  (PMP).  "The  document 
developed  and  issued  by  the  Program  Manager  which 
shows  the  integrated  time-phased  tasks  and  resources 
required  to  complete  the  task  specified  in  the  PMD. 

The  PMP  is  tailored  to  the  needs  of  each  individual 
program.  " (Definition  from  AFR  800-2,  Attachment  3, 

16  March  1972.  ) 

c . Computer  Resources  Integrated  Support  Plan  (CRISP), 

"The  CRISP  identifies  organizational  relationships  and 
responsibilities  for  the  management  and  technical  support 
of  computer  resources.  It  functions  during  the  full-scale 
development  phase  to  identify  computer  resources  necessary 
to  support  computer  programs  after  transfer  of  program 
management  responsibility  and  system  turnover.  The 
CRISP  continues  to  function  after  the  transfer  of  program 
management  responsibilities  and  system  turnover  as  the 
basic  agreement  between  the  supporting  and  using  com- 
mands for  management  and  support  of  computer  resources." 
(Definition  from  AFR  800-14,  Volume  II,  26  September  1975.) 

d.  Computer  Program  Development  Plan  (CPDP).  "The  CPDP 
identifies  the  actions  needed  to  develop  and  deliver  computer 
program  configuration  items  and  necessary  support  resources. 
It  will  be  prepared  by  the  implementing  command  or,  if  the 
development  effort  is  contracted,  the  plan  may  be  prepared 

by  the  contractor  and  approved  by  the  implementing  command.  " 
(Definition  from  AFR  800-14,  Volume  II,  26  September  1975.) 
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A regulation  closely  related  to  AFR  800-14  is  AFR  800-2, 
entitled  "Acquisition  Management  — Program  Management.  " This  is 
the  management  regulation  for  all  Air  Force  acquisition  of  DOD- identified 
major  defense  systems.  The  entire  system  is  managed  according  to 
AFR  800-2,  and  its  computer  resources  are  managed  according  to 
AFR  800-14. 

A large  number  of  other  regulations,  as  well  as  pamphlets  and 
manuals,  are  included  in  the  Air  Force  800  series  of  RSS.  The  series 
as  a whole  covers  the  acquisition  of  entire  systems  from  the  time  the 
requirement  is  initially  approved  until  the  system  is  available  to  the 
operating  command.  The  RSS  bibliography  in  Appendix  B lists  many 
of  these  800  series  documents.  The  major  characteristics  of  the  800 
series  RSS  are  summarized  in  Table  3-6. 

The  Air  Force  has  another  series  of  RSS  — the  300  series  — that 
is  devoted  entirely  to  the  regulation  and  control  of  another  category  of 
computer  systems,  those  that  function  as  independent  data  processing 
systems  rather  than  as  integral  elements  of  larger  systems.  This 
category  is  referred  to  in  regulations  as  automatic  data  processing  (ADP) 
systems  and  is  carefully  distinguished  from  the  "computer  resources" 
embedded  in  major  defense  systems. 

Despite  its  different  subject  matter,  the  300  series  can  play  an 
important  role  in  the  acquisition  and  support  of  embedded  computer 
resources.  For  one  thing,  the  Air  Force  ADP  Program  Single  Manager 
established  by  AFR  300-2,  "Management  of  ADP  Systems",  is  responsible 
for  providing  requested  ADP  technical  and  managerial  information  and 
advice  to  AFR  800-14  programs  through  HQ  USAF  coordination.  In 
addition,  several  regulations  and  manuals  in  the  300  series  can  be 
employed  for  800  series  programs,  including  those  pertaining  to  stan- 
dardization of  data  elements,  equipment,  and  computer  programs  and  use 
of  higher  level  programming  languages.  The  general  relationship  of  the 
800  series  and  300  series  RSS  is  shown  in  Figure  3-1. 
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A.  MISSION  REQUIREMENTS 

New  or  improved  mission  requirements  may  be  initiated  by  any  Air  Force  organization 
or  by  higher  authority.  Requirements  are  transmitted  to  Major  Command  and  HQ  USAF 
in  the  form  of  a Required  Operational  Capability  (ROC)  as  specified  by  AFR  57-1  for 
new  or  improved  operational  capabilities.  HQ  USAF  will  validate  the  requirement,  and 
if  the  requirement  is  approved,  issue  a Program  Management  Directive  (PMD).  The  PMD 
establishes  the  basis  and  authority  for  subsequent  management  of  the  project.  The  direc- 
tive may  specifically  identify  any  regulation  to  be  followed  or  excluded  in  the  acquisition. 

For  airborne  system  software  acquisitions,  it  will  normally  identify  the  AFR  800  series 
as  the  management  policy  and  procedure  directives  to  be  followed. 

B.  ACQUISITION  RESPONSIBILITIES 

The  acquisition  of  assigned  defense  systems,  including  any  necessary  software,  is  the 
responsibility  of  HQ  USAF.  An  implementing  command,  usually  the  Systems  Command, 
is  selected  and  is  given  maximum  authority  and  responsibility  to  acquire  a system.  A 
Program  Manager  is  appointed  and  given  authority  to  act  on  behalf  of  the  implementing 
command  to  conduct  the  acquisition  program  within  the  approved  performance,  schedule, 
and  funding  requirements. 

C.  PROGRAM  MANAGEMENT  RESPONSIBILITIES 

The  Program  Manager  organizes,  plans,  directs,  and  controls  the  entire  program.  He 
prepares  the  Program  Management  Plan  (PMP),  which  is  a directive  on  all  participating 
organizations,  and  establishes  the  scope,  cost,  and  schedule  for  all  program  efforts. 

He  assesses  for  HQ  USAF  all  changes  in  the  PMP,  level  of  effort,  system  requirements, 
cost,  and  schedule.  He  coordinates  the  activities  of  participating  organizations  and 
reports  to  higher  headquarters  the  performance  progress  of  the  program  and  recommended 
changes.  For  selected  programs,  the  Program  Manager  is  authorized  direct  communi- 
cation of  problems  and  recommended  solutions  to  the  commander  of  the  implementing 
command,  the  Chief  of  Staff,  and  the  Secretary  of  the  Air  Force.  An  AFR  800  series 
managed  program  delegates  maximum  authority  and  responsibility  to  the  Program  Manager  . 
Program  review  and  approval  of  such  items  as  system  requirements,  performance, 
schedule,  and  funding  are  responsibilities  of  higher  headquarters. 

D.  PROGRAM  MILESTONES 

The  principal  milestones  of  an  800  series  program  are  the  transition  points  between 
acquisition  life  cycle  phases.  At  these  milestone  points,  specifications  are  baselined  for 
configuration  control  and  reviews  are  conducted.  On  most  programs,  DOD  approval  is 
required  (DSARC)  at  the  end  of  each  of  the  first  three  phases  (conceptual,  validation,  and 
full-scale  engineering  development)  before  the  next  phase  begins.  With  the  approval  of  HQ 
USAF,  the  Program  Manager  may  identify  intermediate  milestones,  in  addition  to  those 
called  out  by  the  regulations  and  standards. 

E.  REVIEWS 

System  requirement  reviews,  system  design  reviews,  preliminary  design  reviews,  and 
critical  design  reviews  are  usually  conducted  in  accordance  with  MIL-STD-1521A  (USAF), 
"Reviews  and  Audits.  " The  design  reviews  are  not  the  means  of  providing  technical  direc- 
tion or  even  of  approving  or  disapproving  the  information  presented.  This  information 
represents  only  the  intended  design  approach  of  the  contractor.  The  assessment  of  that 
information  as  a measure  of  technical  progress  and  design  acceptability  can,  however,  be 
the  basis  for  independent  technical  direction  by  the  Program  Manager. 

F.  REPORTING 

A Program  Manager  continually  assesses  progress,  performance,  and  costs  and  reports 
appropriate  problems  and  recommended  changes  to  a higher  headquarters.  In  addition, 
he  conducts  periodic  reviews,  as  directed  or  as  planned,  for  AFSC,  the  Air  Force,  or  the 
Secretary  of  Defense. 
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Table  3-6.  Major  Characteristics  of 
AF  800  Series  Documents 
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G.  CONFIGURATION  MANAGEMENT 

A Program  Manager  must  employ  a configuration  management  program,  based  on 

AFR  65-3,  "Configuration  Management,"  including  Appendix  F,  that  will  identify 
and  document  functional  and  physical  characteristics  of  all  CPCIs  under  development. 

The  use  of  practices  such  as  those  defined  in  MIL-STD-483  are  a means  of  identifying 
a product  configuration,  obtaining  configuration  status  information,  and  establishing 
baselines  from  which  changes  can  be  proposed,  assessed,  and  recorded.  Although 
not  explicitly  required,  the  procedures  used  are  usually  those  of  MtL-STD-483.  CPCI 
specifications  as  outlined  in  MIL-STD-490  and  MIL-STD-483  are  the  usual  means  of 
documenting  software  requirements  and  design:  development  specifications  describe 
requirements  and  product  specifications  describe  first  the  code-to  design  of  the  CPCI 
computer  programs  and  then  their  as-coded  design. 

H.  SOFTWARE  DOCUMENTATION 

The  AFR  800  series  requires  that  software  be  identified  and  documented  as  one  or  more 
CPCIs.  A Program  Manager  usually  can  use  the  CPCI  specifications  required  for  con- 
figuration management  as  the  foundation  of  his  software  documentation  set  and  add  other 
required  data  items  as  necessary.  A well-balanced  CDRL  (Contract  Data  Requirements 

List,  Form  DD1423)  usually  will  include  system,  development,  and  product  specifications 
to  describe  the  software;  test  plans,  procedures,  and  reports  to  support  the  software 
quality  requirements;  user  manuals  and  perhaps  maintenance  manuals  to  describe  the 
use  and  modification  or  correction  of  the  software;  and  management  and  change  control 
documents.  The  content  of  each  document  is  specified  in  the  CDRL  by  one  of  the  Data 

Item  Descriptions  (DIDs)  listed  in  DOD  5000. 19-L,  Volume  II,  "Acquisition  Management 
Systems  and  Data  Requirements  Control  List  (AMSDL)." 

I.  SOFTWARE  REQUIREMENTS 

Requirements  for  the  software  portion  of  a system  usually  are  first  stated  in  the  system 
specification,  along  with  the  general  requirements  for  the  hardware,  personnel  sub- 
system, and  other  basic  elements  of  the  system.  These  requirements  are  allocated 
from  the  system  requirements  specified  in  the  same  document.  Subsequently  the  soft- 
ware requirements  are  restated  and  further  allocated  to  modules  of  the  software  system 
in  a series  of  CPCI  (computer  program  configuration  item)  development  specifications. 

J.  SOFTWARE  STANDARDS  SELECTION 

AFR  800-14,  Volume  II,  requires  the  use  of  higher  order  languages  (HOLs)  such  as 
FORTRAN,  JOVIAL,  or  COBOL  rather  than  assembly  language,  to  the  maximum 
degree  practical. 

K.  SOFTWARE  TESTING 

AFR  800  series  systems  that  use  the  configuration  management  procedures  of  MIL-STD- 
483  include  in  each  system,  segment,  and  CPCI  development  specification  a section 
(Section  4)  on  the  testing  of  each  requirement  in  the  specification.  Frequently,  a task 
is  included  in  the  statement  of  work  for  preparation  of  test  plans,  test  procedures,  and 
test  reports.  Whenever  a specification  does  not  identify  a particular  test  requirement, 
it  is  presumed  that  success  or  failure  of  a test  of  that  requirement  is  immaterial  to 
acceptance.  The  Air  Force  policies  and  requirements  for  test  and  evaluation  of  all 
systems  acquired  under  AFR  800-2  are  contained  in  AFR  80-14,  "Test  and  Evaluation." 

This  regulation  emphasizes  the  test  and  evaluation  of  systems  for  suitability  and  effect- 
iveness; it  includes  computer  programs  to  the  extent  that  they  are  part  of  a system. 

AFSC  DH  4-2,  "Electronic  Systems  Test  and  Evaluation,  " includes  a Chapter  5 contain- 
ing guidelines  for  test  and  evaluation  of  computer  programs  in  accordance  with  AFR 80-14. 

L.  INTEGRATED  LOGISTICS  SUPPORT 

An  AFR  800  series  program  must  provide  for  an  Integrated  Logistic  Support  Program 
supported  by  system  engineering  and  life  cycle  costing.  The  AFR  800  series  presumes 
that  the  Program  Manager  is  a temporary  agent  of  the  implementing  command  and 
that  when  the  acquisition  task  is  completed,  the  system  will  be  turned  over  to  an 
operating  command  and  to  supporting  commands.  The  Program  Manager  must  anticipate 
the  future  needs  of  the  operating  and  supporting  commands  and  the  recurring  cost  of 
system  operations. 
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Figure  3-1.  General  Relationship  of  AF  800  Series  and 
300  Series  Documents 


Table  3-6  does  not  mention  quality  assurance  because  none  of  the 
AF  800  series  of  RSS,  including  AFR  800-14,  specifically  addresses  the 
need  or  implementation  of  this  discipline.  However,  several  RSS  outside 
the  AF  800  series  provide  quality  assurance  guidelines  compatible  with  the 
AF  800  series  approach: 

a.  MIL-Q-9858A,  Quality  Program  Requirements.  Applies 
primarily  to  hardware  quality  assurance  (d)A)7  hut  men- 
tions several  important  requirements  not  mentioned  else- 
where. (See  MIL-Q-9858A  entry  in  Appendix  A.) 

b.  MIL-S-52779(AD),  Software  Quality  Assurance  Program 
Requirements.  Requires  a contractor  to  establish  and 
implement  a software  QA  program  that  will  assure  that 
delivered  software  complies  with  contract  requirements. 

Applies  to  development  of  software  alone  or  to  software 
as  part  of  a system  or  subsystem.  (See  MIL-S-52779(AD) 
entry  in  Appendix  A. ) 

c.  SAMSOP  74-2.  Contractor  Software  Quality  Assurance 
Evaluation  Guide~  Provides  guidelines  for  evaluating 
contractor  QA  programs  that  are  subject  to  MIL-S-52779 
(AD)  requirements.  (See  SAMSOP  74-2  entry  in  AppendixA. ) 

Additional  information  on  software  QA  will  be  found  in  the  Quality 
Assurance  Guidebook.  Additional  information  on  the  topics  listed  in 
Table  3-6  will  be  found  in  the  following  guidebooks  of  this  series: 

a.  Mission  Requirements.  In  "Contracting  for  Software 
Acquisition"  Guidebook. 

b.  Acquisition  Responsibilities.  In  "Contracting  for 
Software  Acquisition"  Guidebook. 

c.  Program  Management  Responsibilities.  All  guidebooks 
in  this  series  contain  information  on  this  topic. 

d.  Program  Milestones.  In  Section  2 of  this  guidebook. 

Also  in  "Reviews  and  Audits"  Guidebook. 

e.  Reviews.  In  "Reviews  and  Audits"  Guidebook. 

f.  Reporting.  In  "Measuring  and  Reporting  Software 
Status"  Guidebook  and  "Software  Cost  Measuring  and 
Reporting"  Guidebook. 
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g.  Configuration  Management.  In  "Configuration  Management" 
Guidebook. 

h.  Software  Documentation.  In  "Computer  Program 
Documentation  Requirements"  Guidebook  and  "Require- 
ments Specification"  Guidebook. 

i.  Software  Requirements.  In  "Requirements  Specification" 
Guidebook. 

j.  Software  Standards  Selection.  In  Appendix  B of  this  guidebook, 
particularly  subsections  B.  1.4. 8 and  B.2.2. 

k.  Software  Testing.  In  "Verification,  Validation,  and 
Certification"  Guidebook.  For  relation  of  the  quality 
assurance  section  (Section  4)  of  program-peculiar 
specifications  to  testing,  see  the  "Computer  Program 
Documentation"  Guidebook. 

3.3  DOD  STANDARIZATION  PROGRAM 

The  DOD  standardization  program,  established  by  DOD  Directive 
4120.  3,  is  a major  national  effort  to  uniformly  document  management 
and  technical  agreements  and  decisions  applicable  to  more  than  one  DOD 
program.  Military  standards,  military  handbooks,  general  military 
specifications,  and  detailed  military  specifications  are  the  primary 
instruments  for  implementing  this  standardization  program.  These 
documents  supplement  the  Federal  standards  and  Federal  specifications 
issued  by  the  General  Si  rvices  Administration  and  the  adopted  industry 
specifications  and  standards  issued  by  approved  industry  groups. 

More  than  42,000  standardization  documents  are  currently  used 
by  the  Department  of  Defense.  Most  of  these  documents  are  concerned 
with  reprocurement  of  specific  items  of  equipment,  with  standards  for 
specific  parts,  and  with  items  peculiar  to  each  of  the  services.  This 
large  number  may  be  reduced  to  possibly  a hundred  or  so  specifications 
and  standards  that  commonly  are  referenced  in  ASD  and  SAMSO  software 
procurement  contracts. 
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3.4  NON-RSS  PROGRAM -PECULIAR  DOCUMENTS 

One  group  of  documents  essential  to  any  system  acquisition  has 
not  been  discussed  in  the  preceding  parts  of  this  section.  These  are 
the  program-peculiar  plans,  procedures,  manuals,  and  other  documents 
that  a contractor  must  prepare  and  deliver  to  the  procuring  agency  to 
provide  needed  visibility  or  to  permit  operation  and  maintenance  of  the 
system  by  other  organizations.  This  group  includes  such  documents  as 
the  following: 

a.  Computer  Program  Development  Plan  (CPDP) 

b.  System  Engineering  Management  Plan  (SEMP) 

c.  Configuration  Management  (CM)  plans 

d.  Quality  Assurance  (QA)  plans 

e.  Standards  and  conventions 

f.  Program  schedules 

g.  Agenda  for  reviews  and  audits 

h.  Minutes  of  reviews  and  audits 

i.  Configuration  index 

j.  Engineering  Change  Proposal  (ECP) 

k.  Specification  Change  Notice  (SCN) 

l.  Training  support  data 

m.  User  manual 

n.  Positional  handbook 

o.  Computer  programming  manual 

p.  Test  plan,  procedure,  and  report 

These  types  of  program-peculiar  documents,  while  required  by  the  RSS 
system  and  in  some  cases  defined  in  detail  by  RSS,  are  not  themselves 
considered  RSS  because  they  do  not  have  the  kind  of  regulating  or 
standardizing  functions  in  the  acquisition  process  that  RSS  have. 
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Although  similar  in  many  ways  to  program-peculiar  specifications 
such  as  the  system  specification,  development  specification,  and  product 
specification,  these  non-RSS  documents  normally  are  not  used  to  define 
specific  contract  requirements.  For  example,  an  acceptance  test  plan 
and  procedures  document  may  be  used  to  determine  the  acceptability  of 
a product  by  providing  the  means  to  compare  the  product  with  the 
requirements  of  the  system  specification.  The  system  specification 
however,  not  the  test  document,  is  the  primary  measure  of  contractual 
compliance. 

Some  of  the  other  documents  in  this  category  are  instructional 
(user  manuals  and  positional  handbooks),  some  are  administrative 
(agenda,  minutes,  ECP's,  SCN's),  and  some  are  plans  for  management 
control  (CM  and  QA  plans).  These  documents  are  similar  to  some  of 
the  contractor  internal  documents  but  are  deliverable  and  the  contractor 
internal  documents  normally  are  not. 

Because  this  group  of  non-RSS  program-peculiar  documents  must 
be  considered  to  round  out  a complete  program-peculiar  documentation 
set,  this  guidebook  at  times  considers  this  group  and  the  program- 
peculiar  specifications  to  be  part  of  the  same  set.  Section  5,  for 
example,  treats  this  entire  set  together  in  discussing  data  item 
requirements. 
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4.  USING  RSS  AS  COMPLIANCE  DOCUMENTS 


4.1  THE  REFERENCING  PROCESS 

Requirements  to  be  imposed  on  a contractor  for  an  ASD  or  SAMSO 
program  must  be  specified  in  the  statement  of  work  (SOW),  contract 
exhibits,  program-peculiar  specifications,  or  other  program-peculiar 
requirement  documents.  To  reduce  the  number  of  different  practices, 
processes,  and  items  involved  in  procurements,  Armed  Services  Pro- 
curement Regulation  (ASPR)  1-1202  requires  that  contractual  require- 
ments be  established  whenever  possible  by  referencing  existing  military, 
Federal,  and  adopted  industry  specifications  and  standards.  Such  refer- 
encing also  reduces  the  amount  of  detail  present  in  the  contract  documents 
themselves  and  takes  advantage  of  the  accumulated  experience  behind  the 
referenced  documents. 

Software  users,  buyers,  and  developers  have  not  yet  built  up  a 
library  of  specifications  and  standards  to  match  those  of  the  hardware 
industry,  which  has  had  the  advantage  of  more  than  a century  of  stan- 
dardization activity.  Still,  the  number  of  specifications  and  standards 
applicable  to  software  acquisition  is  sufficient  to  permit  standardization 
in  many  areas.  A relatively  small  but  growing  number  of  software- 
unique  or  software-included  specifications  and  standards  is  available, 
as  well  as  some  intended  originally  for  hardware  acquisition  but  suitable 
in  varying  degrees  for  software  also. 

Establishing  contractual  requirements  by  referencing  specifications 
and  standards  involves  all  of  the  legal  obligations  and  perils  associated 
with  any  contractual  agreement.  Ambiguities,  omissions,  and  other 
inaccuracies  are  costly  in  terms  of  confusion,  slipped  schedules, 
unsatisfactory  products,  cost  overruns,  and  support  problems.  It  is 
important,  therefore,  that  the  referenced  specifications  and  standards 
accurately  define  the  requirements  desired.  This  accuracy  is  achieved 
by  selecting  the  specifications  and  standards  that  most  closely  state 
the  desired  requirements  and  then  carefully  tailoring  the  contract 
references  to  supply  any  clarifications  needed. 


Preceding  page  blank 
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To  some  extent,  the  terms  "selection"  and  "tailoring"  can  be 
used  as  synonyms,  meaning  "to  choose  a set  of  specifications  and 
standards  that  establish  the  requirements  for  a procurement.  " This 
guidebook,  however,  makes  this  distinction: 

a.  Selection:  Choosing  a set  of  specifications  and  standards 
that  in  whole  or  in  part  contain  requirements  that  a pro- 
curement must  satisfy. 

b.  Tailoring:  Limiting  or  modifying  the  applicability  of 
the  specifications  and  standards  selected. 


4.2  PROCUREMENT  CONSIDERATIONS 


Some  familiarity  with  procurement  methods  and  contract  functional 
details  will  help  software  acquisition  engineers/managers  to  establish 
more  effective  requirements  and  avoid  hazards.  Important  points  to 
know  include  the  effects  of  statement  of  work  (SOW)  task  statements  on 
contract  specification  documents  and  referenced  compliance  documents, 
the  difference  between  strict  compliance  and  substantial  compliance, 
and  the  importance  of  re-evaluating  established  requirements  as  an 
acquisition  proceeds. 


The  following  few  pageB  touch  only  the  surface  of  this  subject. 
Further  information  is  included  in  the  guidebooks  entitled  "Contracting 
for  Software  Acquisition"  and  "Statements  of  Work  and  Requests  for 
Proposal.  " 


4.2.1  Procurement  Methods 

The  current  basis  of  military  procurement  authority  is  Public 
Law  413,  and  Armed  Services  Procurement  Act  of  1947.  This  law  is 
implemented  and  expanded  by  the  Armed  Services  Procurement  Regu- 
lations (ASPR),  Air  Force  Regulations  (AFR),  Air  Force  System  Com- 
mand Regulations  (AFSCR),  and  Aeronautical  Systems  Division  (ASD) 
and  SAMSO  regulations.  These  regulations  require  that  all  purchases 
and  contracts  for  supplies  and  services  shall  be  made  by  formal  adver- 
tising, unless  they  are  within  the  scope  of  the  specific  exceptions  that 
permit  negotiation.  These  exceptions  are  design  flexibility,  tight 
security,  speed  in  purchasing,  specific  makes  or  models,  or  intentional 
development  of  additional  suppliers. 
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Negotiation  is  a more  flexible  and  relatively  informal  bidding 
process  to  determine  the  best  source  available.  Negotiation  may  be 
competitive  or  non-competitive  . Because  of  the  contracting  officer's 
greater  freedom  of  action  under  negotiation,  this  method  is  particularly 
attractive  for  complex  system  or  equipment  procurement,  particularly 
during  those  phases  of  a program  when  development,  detailed  design, 
and  product  specifications  are  to  be  developed.  ASD  and  SAMSO  needs 
are  such  that  negotiation  is  usually  the  method  selected  by  the  con- 
tracting officer. 

The  general  procedures  used  in  negotiation  include  preparation 
of  a Request  for  Proposal  (RFP),  distribution  of  the  RFP,  receipt  of 
proposals  and  quotations  from  sources  of  supply,  evaluation  of  proposals, 
negotiations  with  suppliers,  and  contract  award.  The  RFP  must  include 
the  following  items: 

a.  Statement  of  Work  (SOW) 

b.  Contract  Data  Requirement  List  (CDRL)  (DD  Form  1423) 

c.  Delivery  Schedule 

d.  List  of  Government  furnished  equipment 

e.  Type  of  contract  proposed 

f.  All  other  provisions  to  be  included  in  the  final 
contract  that  may  affect  price. 

The  general  procedures  used  in  formal  advertising,  the  other 
procurement  method,  include  preparation  of  an  invitation  for  bids, 
distribution  of  the  invitation,  submission  of  bids,  opening  and  evaluation 
of  bids,  and  awarding  of  a contract.  The  invitation  for  bids  must  include 
all  the  information  needed  by  the  prospective  contractors  to  make  a sound 
and  reasonable  bid.  Complete  specifications  to  be  met,  delivery  schedules, 
bond  requirements,  and  all  other  provisions  to  be  included  in  the  final 
contract  must  be  specifically  included  in  the  invitation  to  bid. 
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4.2.2  Typei  of  System  Acquiaition  Contracts 

Government  contracts  for  system  acquisition  generally  are  either 
fixed  price  or  cost-reimbursement  types.  The  decision  as  to  which 
contract  type  to  use  is  a very  important  aspect  of  the  procurement  and 
is  to  a large  extent  based  upon  the  degree  of  definition  of  the  technical 
requirements.  The  tighter  the  contractor's  efforts  can  be  defined,  the 
greater  the  financial  control  that  can  be  placed  on  the  contractor.  For 
efforts  that  can  be  tightly  defined,  fixed  price  contracting  can  be  used, 
with  the  contractor  being  required  to  deliver  a supply  or  service  within 
a ceiling  price.  If  the  contractor  effort  cannot  be  tightly  defined,  a cost- 
reimburseable  contract  should  be  used,  with  the  contractor  required  only 
to  exert  his  best  effort  to  supply  the  service  or  item  within  the  funding 
provided.  Additional  characteristics  of  these  two  kindB  of  contracts  are 
as  follows: 

a.  Fixed  Price  Contracts.  Fixed  price  contracting  refers  to  a 
family  of  pricing  arrangements  whose  common  characteristic 
is  a ceiling  beyond  which  the  Government  bears  no  responsi- 
bility for  payment.  The  most  common  type  is  a firm  fixed 
price  contract  in  which  the  contractor  or  supplier  agrees  to 
furnish  certain  specified  items  or  services  to  the  Government 
for  a certain  price.  The  fixed -price -incentive -fee  (FPIF) 
contract  is  a more  general  arrangement  that  includes  a target 
price  as  well  as  a ceiling  price  that  limits  the  Government's 
liability.  The  contractor  or  supplier  is  motivated  to  keep  his 
costs  low  on  a fixed  price  contract  because  the  lower  his  costs, 
the  higher  his  profit. 

b.  Cost-Reimbursement  Contracts.  The  other  basic  type  of 
system  acquisition  contract  is  t!he  cost -reimbursement  contract. 
This  is  a family  of  pricing  arrangements  that  provide  for  pay- 
ment of  allowable,  allocable,  and  reasonable  costs  incurred  in 
the  performance  of  a contract,  to  the  extent  that  such  costs 

are  prescribed  or  permitted  by  the  contract.  Typically,  the 
contractor  is  reimbursed  for  all  costs  incurred  in  supplying 
the  items  or  in  performing  the  services  identified,  plus  a 
stipulated  fee.  The  cost-reimbursement  contract  allows  a 
fair  price  to  be  paid  in  those  situations  where  exact  costs 
cannot  be  determined  prior  to  performance  of  the  contract. 

The  incentive  for  the  supplier  to  keep  the  costs  low  in  a cost- 
reimbursement  contract  is  usually  less  than  for  an  equivalent 
fixed  price  contract.  Fee  structures  stipulated  in  Government 
procurements  include  fixed  fees;  incentive  fees  based  upon 
contract  cost,  schedules,  or  performance;  award  fees;  or  a 
combination  of  these.  Cost-reimbursement  contracts  are 
always  associated  with  negotiation  and  usually  with  items 
having  a performance  type  specification. 


4.2.3  Contract  Organization 


Government  contracts  are  organized  for  ease  of  tailoring.  The 
typical  organization  of  a system  acquisition  contract  is  shown  in 
Table  4-1.  The  purpose  of  each  of  the  four  parts  is  as  follows: 

a-  Part  I,  General  Instructions.  Part  I may  simply  be  a 
single  page  (the  cover  sheet)  that  includes  a table  of 
contents  for  the  contract  and  appropriate  signature  blocks. 

b.  Part  II,  The  Schedule.  Part  II  identifies  the  unique 
agreements  that  form  the  basis  of  the  contract. 

c*  Part  III,  General  Provisions.  Part  III  includes  the 
mandatory  and  appropriate  optional  clauses  identified 
by  the  ASPR  and  other  Government  regulations. 

Part  IV,  List  of  Documents  and  Attachments.  Section  M, 
a list  of  the  attachments,  exhibits,  and  annexes  to  the 
contract,  is  followed  by  a copy  of  each  of  the  items  listed. 

A contract  attachme nt  is  used  to  establish  requirements 
in  the  attached  document  as  an  alternative  to  establishing 
excessive  text  or  lists  in  the  contract.  An  exhibit  is  used 
to  establish  deliverable  requirements  in  the  attached 
document  as  an  alternative  to  establishing  an  extensive  list 
of  line  or  sub-line  items  in  the  schedule.  (The  term 
"exhibit"  should  not  tie  used  to  identify  any  other  type  of 
contractual  document.  ) An  annex  is  an  attachment  to  an 
attachment. 

The  SOW  usually  is  prepared  as  Attachment  1.  It  is  referenced  in 
Section  E,  Supplies/Services.  The  SOW  may  contain  both  "stand  alone" 
tasks  and  task  statements  that  reference  other  requirement  documents 
to  set  forth  detailed  requirements.  The  SOW  usually  identifies  any 
Government  interfaces  in  t lie  management  of  the  program  and  lists  the 
contractor  tasks  (i.e.  , the  management  systems  to  be  used,  the  studies, 
analyses,  and  tests  to  be  performed,  the  software  and  hardware  items 
to  be  produced,  and  any  services  desired). 

Technical  requirements,  including  system  specifications,  system 
segment  specifications,  and  configuration  item  (Cl)  specifications. 


generally  are  prepared  as  separate  requirement  attachments.  This 


Table  4-1.  Typical  Contract  Format 


Part  I.  General  Instruction* 


Section  A. 
Section  B. 


Section  C. 


Section  D. 


Cover  Sheet 

Contract  Form  and  Representations, 
Certifications,  and  Other  Statements  of 
Offeror 

Instructions,  Conditions,  and  Notices  to 
Offeror 

Evaluation  and  Award  Factors 


Part  II.  The  Schedule 


Section  E. 
Section  F. 
Section  G. 
Section  H. 
Section  I. 
Section  J. 
Section  K. 


Supplies/Services  and  Prices 

Description/Specifications 

Preservation/Packaging/Packing 

Deliveries  or  Performance 

Inspection  and  Acceptances 

Special  Provisions 

Contract  Administration  Data 


Part  III.  General  Provisions 

Section  L.  General  Provisions 

Part  IV.  List  of  Documents  and  Attachments 

Section  M.  List  of  Documents,  Exhibits,  and 
Other  Attachments 
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arrangement  allows  tailoring  of  detailed  requirements  by  the  wording 
used  in  the  SOW  task  statements.  Even  detailed  "compliance"  require- 
ments in  a referenced  requirement  document  can  be  tailored  or  even 
reduced  to  "non-compliance"  by  the  wording  in  the  SOW  task  statement. 
This  possibility  must  be  recognized  by  those  preparing  and  reviewing 
contracts,  SOW's,  annexes,  and  other  referenced  requirement  documents. 
(For  additional  information  on  preparation  of  SOWs,  see  the  guidebook 
entitled  "Statements  of  Work  and  Requests  for  Proposal.  ") 

4.2.4  Contract  Terminology 

Because  the  principal  parties  to  a contract  have  different  points  of 
view,  they  may  be  expected  to  differ  at  times  in  their  interpretation  of 
contract  stipulations,  particularly  where  the  language  is  uncertain  or 
inconsistent.  To  improve  the  prospect  of  a common  understanding  of 
a contract.  Program  Managers  should  strive  for  the  greatest  possible 
clarity  of  language.  The  following  are  essential  precautions: 

a.  Certainty  of  Terms.  Requirements  must  be  stated  in 
precise,  definite,  and  unambiguous  terms. 

b.  Consistency  of  Terms.  The  same  terms  must  be  used  to 
refer  to  things  throughout  the  contract  and  requirements 
documents.  Preparation  of  a good  glossary  of  terms  for 
the  procurement  is  an  important  aid  to  consistency. 

c.  Terms  Defining  Sufficiency  of  Performance.  If  strict 
compliance  to  a requirement  is  desired,  the  requirement 
must  be  specific  and  capable  of  measurement  to  the 
accuracies  specified.  When  such  vague  requirements 
as  "high  reliability,"  "best  design  practices,"  "good 
workmanship,  " or  "suitable  for  the  purpose  intended" 
appear  in  a contract,  it  must  be  assumed  that  only  sub- 
stantial, or  approximate,  compliance  by  the  contractor 
is  required.  Vague  requirements  are  adequate  for  pro- 
ducts whose  characteristics  are  impossible  to  define 
exactly  or  to  measure  in  a universally  acceptable  way, 
but  not  for  products  that  must  conform  strictly  to 
requirements  expressable  in  precise  terms.  Some  pro- 
ducts may  require  a mixture  of  strict  compliance  for  some 
requirements  and  only  substantial  compliance  for  others. 
Misunderstandings  usually  can  be  avoided  by  including  in 
the  quality  assurance  requirements  the  details  of  the 
tests  and  inspections  that  will  be  used  to  determine 
compliance. 
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The  requirements  in  a contract  form  the  baseline  against  which 
all  progress  and  subsequent  contractual  changes  are  measured.  Contract 
changes  are  always  processed  in  writing  by  the  contracting  officer,  and 
other  Government  representatives  must  avoid  any  oral  or  written  com- 
munication with  a contractor  that  might  be  interpreted  as  redirection  or 
modification  of  the  contract. 

The  language  in  a contract  that  defines  the  scope  or  outer  limits  of 
the  contractor's  effort  is  of  critical  importance,  because  work  outside 
the  stated  scope  requires  new  negotiations  on  costs,  price,  fee,  and 
possibly  schedule.  If  the  limits  are  not  clearly  expressed,  it  is  difficult 
to  determine  if  or  where  there  has  been  an  increase  in  scope.  Because 
the  SOW  has  such  an  important  role  in  establishment  of  contract  require- 
ments, deficiencies  in  SOW  language,  approach,  terminology,  and 
content  often  create  problems  throughout  the  acquisition  process. 

Attaining  the  top  five  percent  of  the  required  performance  of  a 
system,  subsystem,  or  other  item  frequently  causes  substantial  cost 
increases  or  schedule  slips.  During  full-scale  development,  it  may  be 
advantageous  to  reevaluate  the  established  requirements  by  means  of 
tradeoff  studies  to  see  if  requirements  can  be  reduced  without  degrading 
essential  overall  program  goals.  Care  must  be  taken,  however,  to 
ensure  that  changing  one  system  requirement  does  not  have  a much  bigger 
effect  elsewhere  in  the  total  life  cycle  cost.  Any  decisions  resulting 
from  tradeoff  studies  must  be  implemented  by  changing  the  requirements 
in  the  contract. 

4.3  SELECTING  RSS  AS  COMPLIANCE  DOCUMENTS 
4.3.1  General  Guidelines  for  Selecting  RSS 


General  guidelines  for  selecting  compliance  documents  to  be  applied 
to  a contract  are  as  follows: 

a.  Using  Internal  Document.  Government  internal  docu- 
ments (see  Table  3-1)  should  never  be  referenced  as 
compliance  documents.  Internal  contractor  documents 
should  not  be  referenced  as  compliance  documents  in 
RFPs  or  during  any  contractor  selection  process,  but 
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certain  such  documents  may  be  appropriate  to  negotiate 
into  a contract  after  contractor  selection  if  they  clarify  the 
basis  of  contractor  performance  and  if  their  use  does  not 
jeopardize  potential  competition  that  may  be  desired  during 
subsequent  program  phases  or  reprocurement.  Care  should 
be  exercised  to  avoid  use  of  contractor  prepared  plans  as 
compliance  documents  where  the  requirements  can  better 
be  expressed  through  established  specifications  or 
standards. 

b.  Using  Appropriate  Specifications  and  Standards.  The 
requirements  of  any  Federal,  military,  or  industry  adopted 
specification  or  standard  may  be  imposed  on  a contractor. 
For  software  procurements,  the  number  of  appropriate 
specifications  and  standards  currently  available  is  not 
large,  perhaps  somewhere  between  one  hundred  and  two 
hundred,  and  many  of  these  are  only  marginally  appropriate. 

c.  Checking  RSS  Adequacy.  The  adequacy  of  a specification  or 
standara  for  a particular  application  must  not  be  assumed. 
The  latest  version  should  be  examined  to  ensure  that  it 
addresses  the  current  need.  References  within  standard- 
ization documents,  for  example,  often  are  illegitimate  in 
that  they  do  not  follow  the  DOD  general  referencing  prin- 
ciples (see  rules  for  compliance  references  in  Table  3-1). 
Types  of  references  to  be  suspicious  of  include  the 
following: 

1.  Handbooks  and  standards  that  reference  anything 
besides  other  handbooks  and  standards.  These 
documents  generally  are  stand-alone  documents 
and  therefore  should  not  reference  specifications. 

2.  General  specifications  that  reference  detailed 
specifications. 

3.  General  compliance  documents  (those  applicable 

to  more  than  one  DOD  program)  that  reference  any 
program-peculiar  specification  (i.e.,  system 
specifications,  system  segment  specifications,  or 
Cl  or  CPCI  specifications). 

4.  General  compliance  documents  (military  specifi- 
cations, handbooks,  or  standards)  that  reference 
any  Government  internal  documents,  such  as 
regulations,  manuals,  and  operating  instructions. 

Any  such  deficiencies  in  a document  that  is  otherwise 
appropriate  for  an  application  can  be  corrected  by 
tailoring. 
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d.  Second-Tier  Documents.  Do  not  reference  in  a contract 
any  second-tier  specifications  or  standards  that  already 
are  an  integral  part  of  a compliance  document  or  are 
referenced  in  a contractual  DID. 

e.  Amendments  and  Revisions.  When  listing  compliance 
documents,  include  any  amendments  and  revisions  that 
are  applicable  and  give  their  dates. 

4.3.2  Misapplication  of  Compliance  References 

A major  problem  in  applying  specifications  and  standards  to  a 
procurement  is  determining  the  optimum  level  for  stating  requirements. 
Special  care  must  be  taken  to  prevent  one  or  more  of  the  following 
unintended  results: 

a.  Inappropriate  Application.  The  most  appropriate  RSS  having 
specific  application  to  the  contract  are  not  selected. 

b.  Overapplication.  Overapplication  has  been  blamed  for 
increasing  acquisition  cost  on  some  programs  without 
reducing  life  cycle  cost.  Some  of  the  many  common 
forms  of  overapplication  are  as  follows: 

1.  Unessential  documents  are  referenced  because  inadequate 
time  was  taken  to  properly  understand  their  function. 

2.  All  provisions  of  the  referenced  documents  are  imposed 
on  the  contractor  to  ensure  maximum  performance, 
without  adequate  regard  to  cost. 

3.  "Potential  high  cost  driver"  specifications  and  standards 
are  not  identified  and  given  proper  attention.  Potential 
high  cost  drivers  are  standardization  documents  that 
establish  general  requirements  whose  applicability 
changes  during  the  program  life  cycle  or  whose  different 
sections  apply  to  different  phases  or  types  of  programs. 
These  documents  should  always  be  identified  by  the  con- 
tractor and  subjected  to  special  management  attention 
by  both  the  contractor  and  the  Government. 

4.  Requirements  or  tasks  accomplished  in  an  earlier  phase 
of  the  program  are  still  included  in  the  current  contract. 

5.  Unintended  requirements  are  imposed  on  the  contractor 
by  references  in  lower-tier  compliance  documents  that 
were  not  adequately  examined. 

6.  More  rigorous  standards  are  imposed  than  are  necessary, 
because  of  a failure  to  discriminate  between  various 
levels  of  requirements  or  because  of  a failure  to  appre- 
ciate the  objectives  of  the  procurement. 
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c. 


i 


Underapplication.  Insufficient  compliance  requirements 
are  imposed  on  the  contractor,  reducing  direct  design  or 
other  acquisition  costs  but  increasing  operation  and 
maintenance  costs. 

d.  Conflicting  Application.  Conflicting  requirements  are 
imposed  by  different  compliance  documents  that  have 
the  same  precedence  level  and  equal  priorities. 

e.  Cast  in  Concrete.  Compliance  references  are  tailored 
once  and  only  once,  at  the  start  of  a procurement,  and 

no  refinement  of  these  references  is  sought  or  permitted. 

To  help  achieve  the  correct  referencing  level,  the  following 
directives  have  been  issued: 

* a.  ASPR  1-1201.  This  ASPR  requires  that  all  references  to 

specifications  and  standards  be  tailored  so  that  purchase 
descriptions  state  only  the  actual  minimum  needs  of  the 
Government. 

b.  AFSC  Regulation  800-25.  This  regulation,  entitled 
"Application  of  Military  Specifications  and  Standards  to 
DOD  Procurement,  " requires  that  specifications  and 
standards  referenced  in  purchase  documents  be  tailored 
to  limit  the  application  of  requirements  to  those  essential 
for,  or  consistent  with,  overall  program  success. 

c.  DOD  Design-to-Cost  Directives.  The  design-to-cost 
principles  that  DOD  has  directed  for  most  acquisition 
programs  are  designed  to  permit  program  offices  and 
contractors  to  trade  off  all  but  the  most  basic  program 
requirements  for  the  purpose  of  achieving  a better  life 
cycle  cost.  These  directives  encourage  program  parti- 
cipants to  question  all  system  requirements  that  affect 
life  cycle  cost  so  that  the  best  balance  between  acceptable 
performance,  schedule,  and  life  cycle  cost  can  be 
achieved.  One  of  the  most  effective  ways  to  identify 

and  limit  requirements  for  these  design-to-cost  objec- 
tives is  to  tailor  the  purchase  document  references  to 
specifications  and  standards. 

4.4  TAILORING  RSS 

Tailoring  of  specifications  and  standards  is  one  of  the  areas  of 
inquiry  of  the  Defense  System  Acquisition  Review  Councils  (DSARCs). 
All  program  managers  should  be  prepared  to  answer  specific  questions 
about  this  subject  at  DSARC  reviews. 
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4.4.1  General  Guidelines  for  Tailoring  RSS 


Tailoring  is  the  process  of  limiting  or  modifying  the  applicability 
of  specifications,  standards,  and  other  documents  referenced  in  a SOW 
and  in  program-peculiar  specifications  so  that  the  responsible  con- 
tractor is  required  to  fulfill  only  those  portions  of  the  referenced  doc- 
uments that  are  consistent  with  minimum  high  priority  program  needs. 
These  needs  typically  include  estimated  development  costs,  operation 
costs,  and  maintenance  costs  as  well  as  the  schedule,  design,  and  per- 
formance constraints  of  the  program. 

Recommendations  on  additional  cost  effective  tailoring  of  com- 
pliance documents  should  be  solicited  from  prospective  contractors  at 
appropriate  times  during  the  acquisition  process.  Care  must  be  taken, 
however,  to  avoid  releasing  information  about  proposed  procurements 
outside  the  Government  prior  to  the  official  release.  Only  the  contracting 
officer  is  authorized  to  discuss  this  kind  of  information  or  release  it 
to  potential  contractors. 

Methods  used  to  tailor  referenced  RSS  include  the  following: 

a.  Specifying  Requirements.  This  is  a list  of  the  applicable 
sections  or  paragraphs  of  a referenced  document.  This 
method  is  used  in  Table  4-2  for  MIL-S-83490. 

b.  Specifying  Exceptions.  This  is  a list  of  the  exempted  por- 
tions of  a referenced  document.  This  method  is  used  in 
Table  4-2  for  MIL -STD-480,  483,  490,  and  1521A. 

c.  Self- Tailoring  Detailed  Requirements.  General  military 
specifications  and  standards  typically  state  requirements 
in  ways  that  self-tailor  the  requirements  in  a detailed  Cl 
or  CPCI  specification.  Either  the  actual  requirements 
or  the  data  needed  to  estimate  the  actual  requirements 
must  be  provided  in  the  detailed  specification.  With  this 
method  the  tailoring  occurs  without  modification  of  the 
referenced  documents. 

d.  Specifying  Required  Values.  Performance  values  desired 
are  added  to  the  document  reference. 
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CONTRACTOR  TASKS 


Compliance  Document 8.  In  the  performance  of  this  contract,  the 
contractor  shall  comply  with  all  of  the  following  documents  of  the  exact 
issue  shown  to  the  extent  specified  in  the  column  entitled,  "Tailored 


Application”: 

Document 

Title 

Tailored  Application 

MIL -STD-480 

68  Oct  30 

Configuration  Control  — 
Engineering  Changes, 
Deviations  and  Waivers 

All  (except  4.  8. 7. 1 . 2,  5, 

6,  7,  8,  and  Appendices 

B,  C) 

MIL-STD-483 

(USAF) 

70  Dec  31 

71  Jun  01 

Configuration  Manage- 
ment Practices  for 
Systems,  Equipment, 
Munitions  and  Computer 
Programs 

All  (except  3.8,  3.9.4, 

3.10  [except  3.10.1] 

3.11,  3 . 12,  and  Appendices 
IV,  XI,  and  XV). 

MIL -STD-490 

68  Oct  30 

Notice  1 

69  Feb  01 

Notice  2 

72  May  18 

Specification  Practices 

All  (except  Appendices  I 
[which  is  replaced  by 
draft  of  MIL  - STD -490 A 
Appendix  I dated  1 Aug 

75],  V,  VII,  VIII,  IX, 

X,  XI,  XIV,  and  XV). 

MIL  - STD -1 521 A 
(USAF) 

76  Jun  01 

Technical  Reviews  and 
Audits  for  Systems, 
Equipment  and  Com- 
puter Programs 

All  (except  3. 7,  5.1.7, 
and  Appendix  G). 

MIL  -S-83490 

68  Oct  30 

Specifications,  Types 
and  Forms 

Types  A,  Bl,  B2,  B3,  B5, 
C4,  and  C5,  Form  1A, 
1A-490  Format /Contents. 
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e.  Supplementing  Requirements.  Descriptive  text  is  added  to 
the  document  reference  to  define  more  clearly  the  intended 
requirements  or  application. 

f.  Restricting  Data  Items.  Because  Government  contracts 
always  limit  a contractor's  responsibility  for  deliverable 
data  to  the  items  on  the  Contract  Data  Requirements  List 
(DD  Form  14Z3),  the  CDRL  itself  is  a tailoring  device. 

It  automatically  eliminates  from  the  delivery  requirements 
any  additional  data  requirements  expressed  or  implied  in 
compliance  documents. 

g.  Extracting  Requirements.  Requirements  are  extracted 
from  specifications  and  standards  instead  of  merely 
referenced.  This  method  facilitates  understanding  of 
requirements  but  may  increase  the  size  of  the  contract 
unduly.  It  also  may  introduce  new  references  or  may 
omit  essential  related  requirements,  such  as  the  quality 
assurance  provisions  for  an  extracted  design  requirement. 

h.  Contractor  Choice.  Many  requirements  can  be  stated  in 
such  a way  that  the  contractor  is  given  a choice.  He  might, 
for  example,  be  permitted  to  choose  between  two  or  more 
suitable  specifications  or  standards  for  a structured 
design  notation. 

i.  Prioritizing  Requirements.  Referenced  requirements  may 
be  tailored  by  establishing  a scale  of  priorities  among  all 
the  purchase  documents.  This  important  and  sometimes 
complex  method  is  discussed  further  in  the  next  subsection. 

4.4.2  Tailoring  by  Prioritizing  Requirements 

At  the  beginning  of  any  new  system  program,  it  iB  not  practicable 
to  define  and  describe  all  technical  requirements  down  to  the  level  of 
detail  ultimately  required.  The  requirements  therefore  are  defined  in 
stages  as  the  program  evolves,  based  upon  tradeoff  studies  and  other 
developments.  At  each  stage,  a prioritizing  of  the  defined  requirements 
is  required  to  establish  guidelines  for  resolving  conflicts  that  usually 
exist  in  requirements  for  any  complicated  system.  Product  accuracy, 
speed,  and  reliability  usually  are  at  odds  with  each  other  as  well  as  with 
the  development  schedule  and  life  cycle  costs.  Unless  some  attempt  is 
made  to  formally  establish  priorities  among  the  basic  program  require- 
ments, informal  and  probably  inconsistent  priorities  will  be  assigned 
by  the  various  participants  as  they  make  decisions  to  resolve  the  con- 
flicts. Establishing  priorities  is  fundamental  to  conducting  requirement 
tradeoff  studies  and  effectively  tailoring  requirements. 
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Unfortunately  no  uniform  way  is  available  to  establish  priorities 
or  to  document  them  or  to  resolve  conflicts  when  they  occur.  One  over- 
all consideration  is  the  order  of  precedence  of  requirements.  The 
general  rule  is  that  requirements  stated  in  a supplied  document  take 
precedence  over  requirements  in  referenced  documents.  For  example, 
contractual  and  SOW  requirements  take  precedence  over  conflict.  > ’ 
requirements  in  program-peculiar  documents  such  as  system  or  CPC  I 
specifications.  Program-peculiar  requirement  documents  take  pre- 
cedence over  the  documents  referenced  therein,  such  as  general  military 
specifications  and  standards.  This  also  means  that  program-peculiar 
specifications  should  reference  only  lower-level  program-peculiar 
specifications.  Otherwise,  conflicts  would  occur  where  specifications 
at  different  levels  would  seem  to  have  precedence  over  each  other. 

The  order  of  precedence  establishes  priorities  only  in  cases  of 
conflict.  Where  there  are  no  conflicts  and  no  other  prioritization,  an 
applicable  requirement  in  a subtier  reference  has  the  same  weight  or 
priority  as  a requirement  in  the  primary  document.  There  are.  however, 
some  general  rules  that  provide  additional  prioritization  of  requirements: 

a.  Specific  or  detailed  requirements  always  take  precedence 

over  general  requirements.  Detailed  military  specifications 
therefore  take  precedence  over  their  corresponding  general 
military  specifications. 

b»  Compliance  requirements  take  precedence  over  goals.  It 
is  often  possible  to  establish  a wide  range  of  acceptable 
values  for  many  of  the  parameters  of  a complex  system. 

By  indicating  minimum  and  maximum  values  and  stating 
which  extreme  is  the  desired  value  or  goal,  it  is  possible 
to  conduct  parametric  trade  studies  to  optimize  the  system. 

For  parameters  where  a wide  range  of  values  is  not 
practical,  the  maximum  acceptable  tolerances  from  the 
nominal  should  be  stated. 

Lacking  other  guidance,  the  contract  fee  structure,  including 
incentive  provisions,  will  establish  top  level  priorities  for  a program  as 
far  as  most  participants  are  concerned.  Although  this  prioritizing  of 
requirements  is  very  general,  its  importance  in  properly  tailoring 
requirements  should  not  be  underestimated. 
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Requirement  conflicts  often  are  the  result  of  erroneous 
assumptions  by  program  personnel,  such  as  the  following: 

a.  Reducing  a particular  contract  cost  will  automatically 
reduce  life  cycle  cost. 

b.  All  contractors  and  suppliers  have  a common  under- 
standing of  the  rules  for  prioritizing  requirements  and 
therefore  will  establish  the  same  priorities. 

c.  Performance  parameters  are  very  important  and  therefore 
always  should  have  the  highest  priority. 

d.  The  program  manager  bears  the  total  responsibility  for 
requirement  priorities  and  conflicts. 

The  program  manager  does  bear  ultimate  responsibility  for  establishment 
and  promulgation  of  guidelines  for  requirement  priorities,  but  all  pro- 
gram personnel  participating  in  requirements  definition  should  be  on  the 
lookout  for  priority  conflicts  and  the  means  to  prevent  them. 

This  is  a troublesome  and  largely  uncharted  area  in  Government 
procurements  and  deserves  more  attention.  Until  more  formal  guidance 
becomes  available,  each  program  should  establish  its  own  set  of  explicit 
guidelines  for  prioritizing  requirements  and  should  review  and  modify 
the  guidelines  as  necessary  whenever  requirements  are  defined  at  a 
lower  level  of  detail.  Furthermore,  the  guidelines  should  be  imposed 
on  all  program  participants. 
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5.  DEFINING  PROGRAM  DATA  ITEMS 

Because  program-peculiar  data  items  form  the  major  channel  for 
communication  of  program  requirements,  design,  and  all  other  primary 
information  required  in  the  acquisition  process,  the  requirements  of  this 
entire  class  of  software  documentation  — both  specifications  and  non- 
specifications — are  discussed  together  in  this  section. 

5.1  DATA  ACQUISITION  PROCESS 

5.1.1  Data  Items 

Data  items  are  the  various  kinds  of  recorded  information  required 
during  the  acquisition  process  to  support  the  management  and  technical 
objectives  of  a program.  All  of  the  following  are  data  items: 

a.  Administration/Management  Data 

• Data  used  to  administer,  manage,  and  enforce  con- 
tractual requirements 

s Data  designed  to  provide  management  visibility 

• Project  management  reporting 

• Milestone  management  technique  data,  such  as 
PERT  or  other  network  information 

e Status  data 

s Milestone  data 

e Problem  statements 

s Plans 

b.  Financial  Data 

e Dollar  expenditures 
e Forecasts 

• Status  data 
e Cost  data 

e Manpower  data 
e Accounting  data 
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Technical  Data 


• Research  and  engineering  data 

• Specifications 

• Standards 
e Manuals 

• Technical  reports 

• Engineering  drawings  and  associated  lists 

• Process  sheets 

• Catalog  item  identifications 

Technical  data  may  consist  of  photographs  and  drawings  as  well 
as  text  and  tables. 

The  Armed  Services  Procurement  Regulations  (ASPR)  consider 
computer  programs,  as  recorded  in  machine -readable  form  on  decks, 
tapes,  or  disks  or  in  human-readable  form  on  listings,  to  be  data  and 
require  that  software  be  listed  on  the  Contract  Data  Requirements  List 
(CDRL),  DD  Form  1423,  along  with  other  types  of  data  items.  AFSC 
requires  that  software  also  be  listed  in  the  contract  schedule. 

Since  all  data  items  are  "documented"  information,  the  terms 
"data  item"  and  "document"  will  be  used  interchangeably  in  this  guidebook. 

5.1.2  Managing  Data  Acquisition 

Data  items  should  be  planned  and  produced  by  organized  data 
management  activity.  Objectives  of  a sound  data  management  program 
include: 

a.  Improving  administration  of  contract  data  requirements. 

b.  Providing  uniform  procedures  for  planning  and  acquiring 
data  for  all  program  phases,  areas,  and  disciplines. 

c.  Attaining  positive  control  of  data  acquisition  through  con- 
tinuous review  of  data  requirements  and  elimination  of  non- 
essential,  ineffective,  and  duplicate  requests  for  data  items. 
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d.  Limiting  acquisition  of  data  items  to  those  selected  from 
DOD  5000. 19-L,  Volume  II  (AMSDL). 

e.  Specifying  contract  data  requirements  on  a CDRL  (DD 
Form  1423)  to  provide  visibility  and  control. 

f.  Deferring  delivery  of  data  until  it  is  needed. 

g.  Promoting  effective  use  of  data  by  all  appropriate 
program  areas. 

h.  Ensuring  that  data  cost  is  justified  by  its  intended  use. 

5.1.3  Data  Acquisition  Package 

The  primary  elements  of  an  RFP  package  related  to  data  acquisition 
are  the  Contract  Data  Requirements  List  (CDRL,  DD  Form  1423),  the 
associated  set  of  Data  Item  Descriptions  (DIDs),  and  the  Statement  of 
Work  (SOW). 

The  CDRL  identifies  each  data  item  the  contractor  is  to  deliver  and 
specifies  its  desired  content  and  format  by  referencing  an  appropriate 
DID.  The  CDRL  also  specifies  date(  s)  of  submission,  frequency  of  sub- 
mission, distribution  addresses  and  number  of  copies,  the  DID  identifier, 
the  reference  to  the  SOW  task  statement  or  to  contract  provisions,  and 
the  inspection  and  acceptance  criteria.  To  supplement  this  information, 
backup  sheets  may  be  attached  to  the  CDRL  and  referenced  in  the  CDRL. 
CDRL  backup  sheets  also  may  be  used  to  tailor  the  data  item  preparation 
instructions  of  a referenced  DID. 

All  data  to  be  acquired  must  be  listed  in  the  CDRL  because  the  con- 
tractor is  not  obligated  to  deliver  any  data  not  included  there.  One  excep- 
tion is  the  contractor  internal  data  acquired  through  the  Data  Accession 
List  (described  in  subsection  5.4.2). 

Including  a SOW  reference  in  the  CDRL  ties  the  data  item  to  the 
SOW  task  description  where  the  contractor  effort  for  preparation  of  the 
data  item  is  identified.  If  a specific  document,  such  as  a user's  manual, 
is  to  be  verified  in  testing,  this  requirement  must  be  addressed  in  the 
SOW  task  description.  The  SOW  task  description  in  turn  should  reference 
the  related  CDRL  sequence  item  number  and  thus  point  to  the  correct  DID. 
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Suitability  of  the  content  and  format  of  each  data  item,  as  specified 
in  its  DIO,  should  be  established  by  review  and  evaluation.  This  suit- 
ability must  take  into  account  the  needs  of  the  task  indicated  by  the  SOW 
reference. 

5.1.4  Data  Item  Descriptions  (DIDs) 

5. 1.4.1  Standard  DIDs 

The  content  and  organization  of  each  data  item  to  be  acquired  from 
a contractor  must  be  defined  in  a DID.  A typical  DID  is  a one-page  to 
five-page  description  of  the  content,  format,  preparation  instructions, 
and  use  of  a data  item  and  bears  a DOD  control  number  that  can  be  used 
in  CDRLiS  to  reference  the  DID.  Some  DIDs  provide  alternate  or 
expanded  descriptions  of  documents  defined  in  Government  standards 
such  as  MIL -STD-490  and  MIL -STD-483.  Others  describe  documents 
not  defined  in  any  formal  standard. 

DOD  5000. 19-L,  Volume  II,  entitled  "Acquisition  Management 
Systems  and  Data  Requirements  Control  List  (AMSDL),  " lists  about  a 
thousand  standard  DOD  DIDs  originated  by  the  AF  and  other  military 
departments  and  by  DOD  agencies  and  offices.  Standard  DIDs  are 
approved  for  general  use.  The  DIDs  related  to  software  represent  a 
wide  spectrum  of  software  concepts  and  terminologies,  and  no  attempt 
to  correlate  related  types  is  evident.  Air  Force  DIDs  are  assigned  the 
block  of  numbers  from  3000  to  3999,  but  some  AF  DIDs  also  appear  in 
the  6000  and  7000  series  blocks.  In  addition  to  the  standard  DIDs,  there 
are  also  unique  DIDs  (UDIDs),  modified  DIDs,  and  "RliD"  DIDs,  all  of 
which  are  discussed  further  in  subsection  5. 1.4.2,  "Tailoring  DIDs.  " 
About  a thousand  UDIDs  are  listed  in  the  AMSDL. 

Part  V of  the  AMSDL  contains  instructions  for  ordering  copies  of 
the  AMSDL  and  copies  of  DIDs  and  UDIDs. 
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Each  standard  DID  and  unique  DID  carries  a prefix  letter  that 
relates  it  to  the  functional  category  most  nearly  describing  the  use  of 
the  data.  The  functional  categories  and  their  corresponding  letters 
are  as  follows: 

A Administrative/Management 
E Engineering  and  Configuration  Documentation 
F Financial 
H Human  Factors 
L Logistics  Support 
M Technical  Publications 
P Procurement/Production 
R Related  Design  Requirements 
S System/Subsyetem  Analyses 
T Test 
V Provisioning 

Revisions  to  a DID  are  indicated  by  an  alpha  character  suffix  (e.g.  , 
DI-E-3119A). 

Table  5-1  lists  64  data  items  applicable  to  software  acquisition, 
operation,  and  maintenance.  Some  of  these  data  items  are  unique  to 
software  while  others  provide  visibility  into  critical  areas  of  software 
development.  The  table  specifies  standard  DIDs  for  all  but  five  items: 

a.  Standard  DIDs  for  the  Computer  Program  Development 
Plan  (CPDP)  and  Quality  Assurance  Plan  currently  are 
under  review  and  have  not  yet  been  assigned  DID  identifiers. 

b.  No  DIDs  exist  for  the  Computer  Resources  Integrated 
Support  Plan  (CRISP)  and  Test  Evaluation  Master  Plan 
(TEMP)  because  these  items  are  not  intended  to  be  pre- 
pared by  contractors.  (A  contractor  participating  in  the 
conceptual  or  validation  phases  may  be  assigned  to 
prepare  the  CRISP,  however.) 
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c.  No  suitable  DID  exists  yet  for  the  Interface  Design 
Specification  (IDS). 

Twenty-five  of  the  data  items  in  Table  5-1  have  been  selected 
for  an  example  software  documentation  set  that  is  discussed  in  sub- 
section 5.3.6  and  is  illustrated  in  the  wall  chart  accompanying  this 
guidebook. 

5. 1.4. 2 Tailoring  DIDs 

It  is  not  always  possible  or  desirable  to  meet  the  data  requirements 
of  a specific  acquisition  program  using  only  existing  standard  DIDs.  The 
applicable  regulations  (AFR  310-1  and  its  supplements)  recognize  this 
and  provide  for  modification  of  existing  DIDs  and  creation  of  new  unique 
DIDs.  These  two  non-standard  types  of  DIDs  provide  the  means  for 
defining  documents  to  meet  specific  needs  not  addressed  in  the  standard 
DIDs.  The  characteristics  of  these  two  non-standard  types  of  DIDs  are 
as  follows: 


a.  Modified  DIDs.  A modified  DID  represents  requirements 
for  which  a standard  DID  is  generally  acceptable,  but  for 
which  there  are  program- specific  needs  (1)  to  clarify 
usage,  (2)  to  reduce  the  scope  by  deletions  from  the 
standard  DID,  or  (3)  to  adjust  the  content  within  the 
intent  and  scope  of  the  standard  DID.  If  such  modifications 
involve  rewriting  the  DID,  they  require  approval  of  the 
AFSC  Data  Management  Office.  A revision  that  can  be 
described  briefly,  however,  or  that  is  to  be  used  only 

one  time,  may  be  specified  directly  on  the  CDRL.  In 
any  of  these  cases,  the  DID  identifier  is  suffixed  by 
" /M  " to  indicate  the  modification. 

b.  Unique  DIDs.  Unique  DIDs  (UDIDs)  represent  requirements 
considered  to  be  unique  to  a command  or  to  an  acquisition 
program  and  therefore  not  suitable  for  general  use.  UDIDs 
generally  are  initiated  to  accommodate  the  data  requirements 
of  new  or  modified  regulations  or  standards.  UDIDs  must  be 
submitted  to  the  AFSC  Data  Management  Office  for  approval. 
UDIDs  are  kept  on  file  and  periodically  reviewed  for  appli- 
cability on  other  programs  and  for  possible  change  to  the 
status  of  standard  DIDs. 
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A third  type  of  non-standard  DID  is  the  "R&D"  DID,  which  reflects 
data  item  requirements  related  to  feasibility  or  experimental  investigations 
that  cannot  be  satisfied  by  any  standard  DID.  "R&D"  DIDs  are  generated 
solely  for  the  unique  requirements  of  a particular  R&D  program  and 
are  denoted  by  prefixing  their  identifiers  with  "R&D.  " "R&D"  DIDs  also 
must  be  submitted  to  the  AFSC  Data  Management  Office  for  approval. 

5.1.5  Procedure  for  Defining  Data  Items 


The  procedure  for  defining  requirements  for  a complete  set  of 
data  items  for  a software  acquisition  may  be  described  in  the  following 
nine  steps: 

a.  Verify  prerequisites. 

b.  Adopt  a data  item  charting  method. 

c.  Establish  tentative  data  item  requirements. 

d.  Identify  mandatory  data  item  requirements. 

e.  Include  requirements  of  the  applicable  RSS  specified 
in  the  Program  Management  Plan  (PMP). 

f.  Incorporate  the  program- unique  data  requirements 
required  by  SOW  tasks. 

g.  Solicit  user  data  item  requirements  with  the  Data 
Call  procedure. 

h.  Consolidate  the  total  data  item  package,  adding  any 
basic  data  item  requirements  not  identified  in  the 
preceding  steps. 

i.  Review  the  total  data  requirements  for  essentiality. 

These  steps  are  described  in  the  following  subsections  (5.2  and  5.3), 
and  some  additional  possible  steps  involving  contractors  are  described 
in  5.4. 
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5.2  PRELIMINARY  STEPS  IN  DEFINING  DATA  ITEMS 


5.2.1  Prerequisites 

Before  requirements  for  the  major  data  items  in  a software 
procurement  can  be  accurately  identified,  certain  other  kinds  of 
information  must  be  available: 

a.  System  Application.  The  intended  use  of  the  system  in 
wnich  the  software  will  be  used  must  be  known.  How 
long  will  it  last?  Who  will  maintain  it?  How  often  will 
it  be  updated  or  upgraded?  These  matters  may  greatly 
impact  the  kind  and  quantity  of  documentation  needed. 

b.  C PC  I Selection.  The  computer  program  configuration 
items  (CPCIs)  must  have  been  identified  and  their  major 
functional  characteristics  defined.  This  information 
normally  is  included  in  the  System  Specification  or 
System  Segment  Specification.  (Division  of  the  software 
product  into  an  excessive  number  of  CPCIs  or  improper 
allocation  of  functions  among  CPCIs  increases  docu- 
mentation problems  by  multiplying  and  complicating 
CPCI  interfaces.  Data  managers  who  suspect  such 
circumstances  should  determine  if  a remedy  is  possible 
before  they  proceed  far  down  the  data  item  definition 
path. ) 

c.  Acquisition  Method.  The  main  features  of  the  acquisition 
method  must  be  known.  The  number  and  relationship  of 
development  contractors  to  be  employed  affects  the  number 
of  interfaces  to  be  defined,  documented,  and  formally 
controlled.  Furthermore,  any  hand-offs,  or  transfers, 

of  responsibility  between  organizations  creates  a need 
for  supporting  documentation.  Such  transfers  become 
even  more  complicated  when  separate  contracts  are 
required  for  different  acquisition  phases.  Finally,  the 
total  number  of  parties  involved  in  the  procurement  — 
buyers,  users,  and  contractors  — and  their  various 
responsibilities  affect  the  program's  basic  information 
needs,  as  well  as  the  need  for  reviews  and  approvals. 

d.  Schedule  and  Budget.  The  buyer's  schedule  constraints  and 
budget  constraints  must  be  known.  Since  the  schedule  in 
the  CDRL  is  essentially  the  schedule  of  the  entire  program, 
an  impossible  document  delivery  schedule  is  a threat  to  the 
entire  project.  Similarly,  if  the  budget  is  insufficient  to 
finance  the  data  items  considered  mandatory,  some  budget 
readjustments  may  be  necessary. 


- 58  - 


If  some  of  these  items  of  information  are  not  available,  the 
data  item  definition  task  may  be  performed,  but  the  results  should  be 
carefully  reviewed  later,  when  all  of  these  fundamental  facts  have  been 
established. 

5.2.2  Data  Requirement  Charts 

An  extremely  helpful  tool  for  the  data  item  definition  process  is 
a visual  display  of  the  data  items  in  relation  to  each  other  and  to  some 
structured  aspect  of  the  program,  such  as  the  life  cycle.  Figure  5-1 
is  an  example  of  a program  life  cycle  chart  that  includes  all  25  items 
of  a basic  documentation  set  for  software  acquisition.  (Table  5-2  explains 
how  this  documentation  set  was  selected.  ) In  addition  to  the  kinds  of 
information  shown  in  Figure  5-1,  known  dates  should  be  included  for 
key  events  or  transition  points.  These  dates  are  important  to  know  when 
evaluating  the  realism  of  a proposed  documentation  set.  Multiple  diagrams 
may  be  required  to  document  parallel  activities  performed  by  different 
groups  or  to  show  the  additional  data  items  of  a larger  documentation 
set. 

Another  useful  type  of  chart  is  the  documentation  tree,  in  which 
data  items  are  related  to  the  system  hierarchy  (e.g.,  system,  subsystem, 
module,  routine). 

5.3  PREPARING  THE  CDRL 

5.3.1  Tentative  Data  Requirements 

Data  requirements  definition  should  begin  with  a tentative  list  or 
chart  that  identifies  the  functional  areas  that  will  have  data  requirements 
and  the  times  in  the  program  life  cycle  when  these  data  items  will  be 
needed. 

5.3.2  Mandatory  Requirements 

Some  data  items  are  mandated  by  current  policies  or  by  the  specific 
requirements  of  the  Program  Management  Directive  (PMD)  and  the 
Program  Management  Plan  (PMP).  For  example,  a Computer  Resources 
Integrated  Support  Plan  (CRISP)  and  a Computer  Program  Development 
Plan  (CPDP)  are  required  under  current  USAF  policies. 
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Figure  5-1.  Example  of  Life  Cycle  Model 


With  Basic  Documentation  Set 
for  Software  Acquisition  (larger 
version  of  this  figure  in  pouch 
inside  back  cover) 
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5.3.3  Requirements  of  PMP-Referenced  RSS 


Data  requirements  of  the  applicable  regulations,  specifications, 
and  standards  referenced  in  the  Program  Management  Plan  (PMP)  must 
be  included.  For  example,  the  applicability  of  MIL -STD-483  (USAF) 
and  MIL-STD-1521A  (USAF)  in  the  PMP  implies  that  certain  program- 
peculiar  specifications  are  required. 

Requirements  for  program-peculiar  software  documentation  reside 
primarily  in  the  following  RSS: 

a.  AFR  800-14,  Volume  II,  11  Acquisition  and  Support  Procedures 
for  Computer  Resources  in  Systems.  " This  regulation  devotes 
a chapter  (Chapter  7)  to  documentation  requirements  and 
acquisition.  Documentation  also  is  addressed  in  the  context 

of  various  aspects  of  acquisition,  including  planning  (sections 
3-4  through  3-9),  engineering  management  (4-5,  -6,  -7,  -9), 
testing  (5-5),  configuration  management  (6-5,  -6,  -7,  -8,  -9), 
and  contractual  requirements  (8-4,  -5,  -6). 

b.  MIL  -STD-483  (USAF)  "Configuration  Management  Practices 
for  Systems,  Munitions,  and  Computer  Programs.  " This 
standard  supplements  MIL -STD-490  in  the  definition  of  the 
content  and  organization  of  system  and  segment  specifications 
(Appendix  III)  and  CPC  I development  and  product  specifications 
(Appendix  VI).  In  addition,  MIL -STD -483  defines  the  content 
and  usage  of  Engineering  Change  Proposals  (ECPs)  for  soft- 
ware (Appendix  XIV)  and  various  status  accounting  tools  useful 
in  change  control  (Appendix  VIII). 

c.  MIL -STD-1521  A (USAF)  "Technical  Reviews  and  Audits  for 
Systems,  Equipments,  and  Computer  Programs.  11  This  stand- 
ard prescribes  the  requirements  for  the  conduct  of  technical 
reviews  and  audits  in  conjunction  with  the  documents  defined 
in  MIL-STD-483  (USAF).  Specific  direction  is  provided  con- 
cerning the  review  and  audit  of  CPCIs  and  their  associated 
documentation.  Each  type  of  review  or  audit  is  described  in 
an  appendix  to  the  standard. 

d.  AFR  310-1  "Management  of  Contractor  Data.  11  This  regulation 
sets  forth  the  policies,  procedures,  and  responsibilities  govern- 
ing contractor  documentation  (data)  requirements.  Of  par- 
ticular importance  are  the  Data  Call,  preparation  and  review 

of  documentation  requirements,  preparation  of  the  Contractor 
Data  Requirements  List  (CDRL),  and  data  item  description 
(DID)  processing. 
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5.3.4  SOW  Program- Unique  Requirements 

Additional  data  requirements  may  be  derived  directly  from  task 
descriptions  in  the  SOW.  All  special  studies,  evaluations  and  analyses 
identified  in  the  SOW  should  result  in  formal  reports.  Such  program- 
unique  requirements  for  documentation  require  unique,  or  at  least 
tailored,  data  items.  Each  entry  in  the  CDRL  for  one  of  these  data  items 
must  reference  the  SOW  task  that  requires  preparation  of  the  data  item. 

5.3.5  User  Requirements  (Data  Call) 

The  Data  Call  procedure  established  by  AFR  310-1  is  used  to 
survey  the  future  data  needs  of  using  and  supporting  commands.  The 
Data  Call  is  a formal  request  from  the  program  data  manager  to  all 
organizations  participating  in  the  acquisition,  asking  them  to  identify 
the  data  they  will  require.  Each  responding  activity  is  required  to 
express  its  data  requirements  in  terms  of  approved  or  proposed  DIDs 
(DD  Forms  1664)  and  to  document  these  requirements  on  a CDRL  form 
(DD  Form  1423)  containing  delivery  schedule  information. 

Software  users  should  have  a strong  interest  in  defining  the  docu- 
mentation they  will  be  receiving  with  the  software.  Users  often  are 
satisfied  to  receive  a good  set  of  user  manuals  and  product  specifications. 
Some  users,  however,  may  want  certain  types  of  test  documents,  test 
results,  and  operations  manuals  before  accepting  the  software.  They 
also  may  think  it  advisable  to  get  involved  in  the  development  process 
earlier  by  reviewing  the  proposed  requirements  and  proposed  design 
before  a line  of  code  is  written.  For  large  systems,  a user  organization 
may  insist  that  a simulation  of  the  proposed  design  be  built  so  that  the 
users  can  operate  it  and  verify  that  the  design  will  solve  their  problem. 
All  such  user  decisions  affect  the  data  requirements. 

5.3.6  Consolidation  of  Requirements 

The  program  data  manager  reviews  all  CDRLs  resulting  from  the 
Data  Call  and  consolidates  them  into  a single  document  set  listed  in  a 
single  CDRL,  together  with  the  data  requirements  from  other  sources 
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(i.e.,  subsections  5.3.1  through  5.3.4).  In  the  process,  he  eliminates 
any  redundancies,  coordinates  data  requirements  that  are  similar,  sees 
that  all  functional  areas  of  the  program  are  provided  for,  and  ensures 
that  the  resulting  CDRL  is  compatible  with  DOD  5000. 19-L,  Volume  II 
(AMSDL).  He  should  determine  that  all  essential  items  in  the  following 
major  data  categories  have  been  included: 

a.  Contractual  Baseline  Documents.  Contractor  documents 


that  become  part  of  the  contract  as  compliance  requirements. 
Examples:  system,  development,  and  product  specifications. 

b.  Verification  Documents.  Documents  used  to  determine  com- 
pliance with  the  contract,  to  certify  that  services  or  deliveries 
are  accomplished,  or  to  confirm  acceptability  of  products. 
Examples:  test  plans  and  procedures. 

c ■ Visibility  Documents.  Documents  used  as  a basis  for  manage- 
ment decisions  and  evaluation  of  progress.  Examples:  status, 
progress,  and  analysis  reports. 

d-  Government  Involvement  Documents.  Documents  that  define 


requirements  for  use  of  Government  furnished  property  or 
facilities  or  that  call  for  participation  of  Government  per- 
sonnel. Examples:  System  Allocation  Document,  Personnel 
Subsystems/Human  Factors  Development  Program. 

e-  Follow-On  Documents.  Documents  required  beyond  the 

development  effort.  Examples:  operational  manuals,  hand- 
books, and  descriptive  material  needed  for  maintenance 
or  modification  of  the  system  software,  including  support  and 
utility  software  and  test  tools. 

Some  data  items  fall  into  more  than  one  of  the  above  categories. 

A basic  set  of  25  data  items  suitable  for  Air  Force  software  pro- 
curements is  shown  in  Table  5-2,  together  with  the  reasons  for  selection 
of  these  particular  data  items.  Considerable  latitude  is  possible  in  this 
selection  process,  depending  on  the  type  of  procurement,  the  anticipated 
roles  of  contractors  and  Government  agencies,  and  the  nature  of  the  soft- 
ware to  be  acquired. 
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After  achieving  a coherent,  consolidated  documentation  eet,  the 
data  manager  should  perform  a preliminary  evaluation  of  data  item 
essentiality  versus  cost  in  preparation  for  a more  formal  CDRL  review 
(described  in  subsection  5.3.7).  The  goal  of  this  evaluation  is  to  ensure 
that  only  those  data  items  essential  to  acquisition,  operation,  or  main- 
tenance are  included. 

5.3.7  Review  of  Essentiality 

Before  the  consolidated  CDRL  is  issued  as  part  of  an  RFP  and  again 
before  it  is  incorporated  into  a development  contract,  a special  Data 
Requirements  Review  Board  (DRRB)  should  review  it  for  the  following 
qualities: 

a.  No  duplication  or  overlap  of  data  requirements. 

b.  Consistency  of  the  document  set  with  the  procuring  organiza- 
tion's acquisition  policies  and  with  Government  procurement 
policies. 

c.  Consistency  of  the  document  set  with  its  intended  uses. 

d.  Essentiality  of  each  data  requirement  and  the  set  as  a 
whole.  Individual  data  items  must  be  found  essential  to 
present  or  future  management  of  the  program,  to  system 
operation,  or  to  software  maintenance. 

e.  Reasonableness  of  delivery  dates. 

f.  Inclusion  of  contractual  provisions  to  ensure  that  the 
documents  received  will  be  fit  for  their  intended  use. 

Before  contract  award,  the  DRRB  should  review  the  CDRL  again 
to  evaluate  the  contractor's  price  estimate  and  to  ensure  that  data 
requirements  have  not  deteriorated  during  negotiations. 

Following  a successful  DRRB  review,  the  approved  CDRL  should 
be  transmitted  to  the  procuring  officer  for  inclusion  in  the  appropriate 
procurement  instrument. 
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Table  5-2.  Ratio 
Set  fo 

nale  for  Select 
r Software  Ac! 

. 

CDRL  Preparation  Step 

Item  No. 

DID  Identifier 

Data  Item  Name 

i 

A.  Mandatory 

1. 

E-30145  (to  be 

Computer  Software  /Computer  Program/ 

Required  per  ASPR 

Requirements 

published  soon 

Computer  Data  Base  Configuration  Item(s) 

on  decks,  tapes,  op 

in  AMSDL) 

as  on  computer  listl 

2. 

(No  DID  exists.  ) 

Computer  Resources  Integrated  Support 

Required  under  USA 

Plan  (CRISP) 

3. 

(AFSC  DID 

Computer  Program  Development  Plan  (CPDP) 

Required  under  USA 

under  review.) 

B.  Requirements  of 

4. 

(No  DID  exists. ) 

Interface  Design  Specification 

Defines  interfaces  fl 

PM  P-  Referenced 

organizations,  or  b< 

RSS 

developed  by  the  sal 

5. 

E-1101 

System  (Segment)  Specification 

Defines  the  system  1 

functional  requireffl 

6. 

E-3119A 

Computer  Program  Development  Specification 

Defines  the  CPCI  al 

requirements. 

7. 

E-3120A 

Computer  Program  Product  Specification 

Defines  the  CPCI  <U 

C.  SOW  Program- 

.. 

_ _ 

_ _ 

No  SOW  program-d 

Unique  Requirements 

to  be  developed  has 

analysis  or  develop! 

D.  User  Requirements 

8. 

M - 3409 

Positional  Handbook 

Required  for  systeq 

(Data  Call) 

to  the  prime  missioi 

9. 

M - 3410 

Users  Manual 

Provides  instruct^ 

10. 

M-3411 

Computer  Programming  Manual 

Provides  programs^ 

or  modification  of  ij 

It. 

M-3415 

Catalog  and  Glossary  of  Computer  Program 

Describes  and  croej 

and  Programming  Documentation 

documentation  devsj 

acronyms,  and  terfl 

E.  Other  Basic 

12. 

A -3027 

Data  Accession  List/Internal  Data 

Requirements 

These  data  items  Ip 

• Acquisition 

13. 

A - 3029 

Agenda- -Design,  Reviews,  Configuration 

Management 

Audits,  and  Demonstrations 

14. 

E-3118 

Minutes  of  Formal  Reviews  and  Audits 

15. 

E-3108 

Configuration  Management  Plan 

16. 

E -3121 

Version  Description  Document  (Computer 

Program) 

.These  data  items  fp 

both  software  and  w\ 

• Configuration 

17. 

E-3122 

Configuration  Index  (Computer  Program) 

Management 

•< 

18. 

E-3123 

Change  Status  Report  (Computer  Program) 

19. 

E-3134 

Specification  Change  Notice  (Computer 

Program) 

[20. 

H-5076A 

Computer  Software  Change  Proposal 

• Quality  Assurance 

21. 

(No  DID  exists. ) 

Quality  Assurance  Plan 

Describes  plan  fori 

compile,  with  requl 

22. 

T -3703 

Category  I (C PCI/Segment)  Test  Plan/ 

Procedures  (Computer  Programs) 

23. 

T-3717 

Category  I (CPCI/Segment)  Test  Report 

The.e  data  item.  *1 

« 

(Computer  Programs) 

and  ayatem  level.. 

• Teat 

24. 

T-3706 

Category  II  (System)  Test  Plan/Procedures 

[25. 

T-3719 

Category  II  (System)  Test  Report 

* 

Table  5-2.  Rationale  for  Selection  of  Example  Documentation 
Set  for  Software  Acquisition 


r— 

r*P 

Item  No. 

DID  Identifier 

Data  Item  Name 

Comments 

1. 

E-30145  (to  be 
published  soon 
in  AMSDL) 

Computer  Software /Computer  Program/ 
Computer  Data  Base  Configuration  Item(s) 

Required  per  ASPR  to  acquire  the  software  itself,  recorded 
on  decks,  tapes,  or  other  computer -readable  media,  as  well 
as  on  computer  listings. 

2. 

(No  DID  exists. ) 

Computer  Resources  Integrated  Support 

Plan  (CRISP) 

Required  under  USAF  policy. 

3. 

(AFSC  DID 
under  review. ) 

Computer  Program  Development  Plan  (CPDP) 

Required  under  USAF  policy. 

4. 

(No  DID  exists. ) 

Interface  Design  Specification 

Defines  interfaces  between  software  items  developed  by  different 
organizations,  or  between  different  types  of  software  items 
developed  by  the  same  organization  (MIL-STD-483,  Appendix  11). 

5. 

6. 

E-3101 

E-3119A 

System  /Segment)  Specification 

Computer  Program  Development  Specification 

Defines  the  system  (or  segment) 
functional  requirements. 

Defines  the  CPCI  allocated 
requirements. 

These  MIL-STD-483  (USAF) 
specifications  (Appendices 

III  and  VI)  are  required 
for  most  software  develop- 
ment programs. 

7. 

E-3120A 

Computer  Program  Product  Specification 

Defines  the  CPCI  design. 

nents 

-- 

-- 

-- 

No  SOW  program- unique  data  items  are  required  if  the  software 
to  be  developed  has  only  routine  functions  that  need  no  special 
analysis  or  development  tasks. 

8. 

M - 3409 

Positional  Handbook 

Required  for  systems  in  which  a human  operator  is  essential 
to  the  prime  mission. 

9. 

M -3410 

Users  Manual 

Provides  instructions  for  operational  use  of  the  software. 

10. 

M - 341 1 

Computer  Programming  Manual 

Provides  programming  information 
or  modification  of  the  software. 

required  for  maintenance 



If. 

M-3415 

Catalog  and  Glossary  of  Computer  Program 
and  Programming  Documentation 

Describes  and  cross-references  the  software  and  software 
documentation  developed  for  a system  and  defines  abbreviations,  ! 
acronyms,  and  terms. 

12. 

A -3027 

Data  Accession  List/Internal  Data 

1 

13. 

A -3029 

Agenda- -Design,  Reviews,  Configuration 

Audits,  and  Demonstrations 

These  data  items  facilitate  acquisition  management  tasks. 

14. 

E-3118 

Minutes  of  Formal  Reviews  and  Audits 

\ 

15. 

E-3108 

Configuration  Management  Plan 

4 

16. 

17. 

E-3121 

E-3122 

Version  Description  Document  (Computer 
Program) 

Configuration  Index  (Computer  Program) 

.These  data  items  facilitate  configuration  management  of 
both  software  and  software  documentation  items. 

18. 

E-3123 

Change  Status  Report  (Computer  Program) 

19. 

E-3134 

Specification  Change  Notice  (Computer 

Program) 

[20. 

H-5076A 

Computer  Software  Change  Proposal 

ranee 

21. 

(No  DID  exists. ) 

Quality  Assurance  Plan 

Describes  plan  for  assuring  that  software  delivered 
complies  with  requirements  of  the  contract. 

22. 

T -3703 

Category  I (C PCI/Segment)  Test  Plan/ 
Procedures  (Computer  Programs) 

4 

23. 

T -3717 

Category  I (CPCI/Segmcnt)  Test  Report 
(Computer  Programs) 

1 The,,  data  item,  support  testing  at  CPCI,  segment, 
fand  system  levels. 

24. 

T -3706 

Category  II  (System)  Test  Plan/ Procedures 

- - 

[2s. 

T -3719 

Category  II  (System)  Test  Report 

5.4  ACQUIRING  ADDITIONAL  CONTRACTOR  DATA 


5.4.1  Precontractual  Contractor  Data 

Certain  types  of  contractor  prepared  data  may  be  acquired 
precontractually  for  use  in  contractor  evaluation  and  selection.  These 
data  items  include: 

a.  Computer  Program  Development  Plan  (CPDP) 

b.  Configuration  Management  Plan  (CMP) 

c.  Systems  Engineering  Management  Plan  (SEMP) 

d.  Quality  Assurance  Plan 

e.  Human  Engineering  Design  Approach 

f.  Personnel  Subsystem  Test  and  Evaluation  Plan 

g.  System  Safety  Plan 

Such  documents  are  used  to  evaluate  contractor  understanding  of  con- 
tractual requirements  and  capability  to  comply  with  such  requirements. 

For  large  software  procurements,  certain  required  manuals  and 
handbooks  may  depend  on  the  design  approach  and  therefore  are  not 
clearly  identifiable  through  a Data  Call  procedure.  In  such  a case, 
contractors  should  be  required  to  address  specific  operational  and 
support  documentation  in  their  proposal  plans  for  developing  technical 
documentation. 

Precontractual  documents  for  the  foregoing  purposes  are  obtained 
by  including  the  data  requirements  in  the  RFP  CDRL,  providing  the 
related  DIDs,  and  identifying  the  documents  in  the  instructions  for 
Proposal  Preparation  (IFPP),  also  sometimes  called  Instructions  to 
Offerers.  If  incorporated  into  a contract  or  SOW,  these  documents 
establish  contractual  requirements. 
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5.4.2  Additional  Data  After  Contract  Award 


Additional  data  may  be  acquired  after  contract  award  by  the  three 
following  methods: 

a.  Data  Accession  List.  The  acquisition  of  a Data  Accession 
List/Internal  Data  (DID  A-3027)  from  a contractor  ensures 
the  procuring  program  access  to  all  data  generated  by  the 
contractor  for  his  own  use  in  performing  the  contract.  This 
data  includes  interim  and  supporting  technical  documentation 
and  management  documentation  not  otherwise  available, 
such  as  plans,  schedules,  intermediate  development  mile- 
stones, and  resource  allocations.  The  requirement  for 

a Data  Accession  List  must  be  included  on  the  CDRL,  how- 
ever, and  a corresponding  SOW  task  or  contract  provision 
is  required,  specifying  that  the  contractor  is  to  maintain  a 
list  of  all  data  that  he  generates  for  internal  use.  Requested 
data  is  supplied  in  the  contractor's  own  format. 

b.  Deferred  Delivery.  This  method  consists  of  timing  the 
delivery  of  data,  or  of  the  software  itself,  to  a firmopera- 
tional  need  whose  data  cannot  be  established  at  the  time  of 
contract  award.  The  deferred  items  still  must  appear  on  the 
CDRL,  but  with  the  time  and/or  place  of  delivery  not  specified. 
The  contractor  is  expected  to  price  the  data  at  the  time  of 
contracting  and  to  incur  data  preparation  costs  prior  to  the 
call  for  delivery.  The  use  of  deferred  delivery  requires  an 
enabling  clause  in  the  contract  (see  ASPR  7-104.  9(d)). 

c.  Deferred  Ordering.  This  method  applies  to  cases  where  data 
generated  in  performance  of  the  contract  is  required  by  the 
Government  even  though  not  specified  in  the  contract  as 
deliverable  data.  Such  data  is  acquired  through  negotiation 
of  delivery  dates  and  preparation  costs.  The  cost  of  gener- 
ating the  data  is  not  an  additional  cost  subject  to  negotia- 
tion, however,  since  it  was  part  of  the  contracted  effort. 

There  is  no  data  entry  in  the  CDRL  for  such  items,  but  the 
contract  must  include  an  enabling  clause  (ASPR  7-104.  9(m)) 
and  the  clause  entitled  "Rights  in  Technical  Data  and  Com- 
puter Software.  " This  is  the  only  one  of  these  three  methods 
that  requires  negotiation  of  costs  for  the  additional  data 
requested. 

5.5  ALTERNATE  STANDARDS  FOR  SOFTWARE  DOCUMENTATION 

In  addition  to  the  Air  Force  standard  data  items  discussed  in  the 
preceding  parts  of  this  section,  other  defense  agencies  have  published 
various  standards  and  specifications  for  entire  sets  of  software  docu- 
mentation. The  documents  prescribed  in  these  other  standardization 
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sources  may  be  used  for  defining  new  DIDs  for  Air  Force  software 
procurements  where  appropriate,  or  at  least  may  provide  models  for 
revising  or  expanding  standard  DIDs. 


The  two  current  alternate  documentation  standards  offering  the 
most  potential  to  airborne  system  software  procurements  are: 

a.  DOD  7935. 1-S,  "Automated  Data  Systems  (ADS) 

Documentation  Standards" 

b.  SECNAVTNST  3560.1,  "Tactical  Digital  Systems 
Documentation  Standards" 

Another  standard,  WS-8506,  Rev.  1,  "Requirements  for  Digital 
Computer  Program  Documentation,  " 1 Nov.  1971,  formerly  issued  by 
the  Naval  Ordnance  Systems  command,  has  been  superseded  by 
SECNAVTNST  3560.  1,  listed  above. 

Before  any  document  types  included  in  such  standards  are  selected 
or  adapted  to  an  AF  800  series  procurement,  careful  consideration  must 
be  given  to  possible  effects  on  related  management  practices,  reviews 
and  audits,  and  associated  documentation.  Furthermore,  the  two  standards 
listed  above  specifically  address  certain  types  of  computer  applications: 
general  purpose  computers  for  DOD  7935. 1-S  and  shipboard  tactical 
systems  for  SECNAVINST  3560.1.  At  the  same  time,  however,  these 
standards  describe  a complete,  integrated  set  of  documents  at  a uniform 
level  of  detail,  something  that  the  Air  Force  standard  DIDs  do  not  do. 
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APPENDIX  A 
SUMMARIES  OF  KEY  RSS 

The  RSS  summarized  in  this  appendix 
are  listed  in  Table  3-3  in  Section  3. 


Preceding  page  Hank 
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A.  1 INTERNAL  DOCUMENTS 


A. 1.1  POD  Documents 

DOD  4120.  3-M  - 3 January  1972 

STANDARDIZATION  POLICIES,  PROCEDURES,  AND  INSTRUCTIONS 

A.  Purpose.  This  directive  establishes  policies  and  responsibilities 
criteria  for  application  to  design,  development,  procurement,  production, 
and  support  of  DOD  equipment  and  supplies. 

B.  Outline  of  Contents 


Chapter  1.  General  Policies 

Chapter  2.  Policies  and  Procedures  for 
Standardization  of  Documents 


Chapter  3.  Studies  and  Working  Groups 

Chapter  4.  Qualified  Products  Lists 

Chapter  5.  Outline  of  Form  and  Instructions  for 
the  Preparation  of  Specifications  and 
Associated  Documents 


Chapter  6.  Military  Outline  of  Form  and  Instructions 
for  the  Preparation  of  Standards  and 
Handbooks 


Chapter  7.  Procedure  for  Determination  and 

Implementation  of  Item  Standardization 
Status  Coding 


C.  Comments . A good  document  for  becoming  familiar  with 
military  standard  and  military  handbook  formatting  and  revision  pages. 


DODD  5000. 1 - 18  January  1977 
MAJOR  SYSTEM  ACQUISITIONS 


A.  Purpose.  This  DOD  directive  is  used  by  DOD  component  heads 
for  acquisition  of  major  defense  systems  designated  by  the  Secretary  of 
Defense. 


B.  Outline  of  Contents 

1.  Purpose 

2.  Application 

3.  Policy 

a.  Mode  of  Operation 

b.  Conduct  of  Program 

c.  Program  Considerations 

4.  Implementation 

C • Comments.  The  Air  Force  implements  this  directive  via 
AFR  800-2.  The  18  January  1977  version  of  DODD  5000.1  is  a reissue 
that  cancels  the  22  December  1975  version. 
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DODD  5000.2  - 18  January  1977 
MAJOR  SYSTEM  ACQUISITION  PROCESS 


A.  Purpose.  This  directive  defines  the  policies  and  procedures 
used  by  the  DOD  in  the  decision-making  process  for  acquisition  of  major 
systems . 


B.  Outline  of  Contents 

I.  Purpose 

II.  Applicability  and  Scope 

III.  Definitions 

IV.  Policies  and  Procedures 

V.  Effective  Date  and  Implementation 

C.  Comments.  This  directive  supplements  DODD  5000.1  and 
establishes  the  Defense  System  Acquisition  Review  Countil  (DSARC)  charter. 
It  is  a key  directive  for  acquisition  of  embedded  computer  systems. 
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DODD  5000.3  - 20  May  1975 
TEST  AND  EVALUATION 


A.  Purpose.  This  directive  establishes  policy  for  the  test  and 
evaluation  of  defense  systems  programs.  It  can  be  used  by  contracting 
officials  to  prepare  or  review  software  test  plans,  test  procedures,  and 
test  report  documents. 

B.  Outline  of  Contents 


I.  Purpose 

II.  Cancellations 

III.  Scope  and  Applicability 

IV.  Policies  and  Principles 

A.  General 

B.  Development  Test  and  Evaluation 

C.  Operational  Test  and  Evaluation 

D.  Test  and  Evaluation  for  Major  Ships  of  a Class 

E.  Test  and  Evaluation  for  One-of-a-Kind  Systems 

F.  Production  Acceptance  Test  and  Evaluation 

G.  Test  and  Evaluation  Master  Plan 

H.  Changes  to  Test  and  Evaluation  Plans 

I.  Defense  Systems  Acquisition  Review  Council 
(DSARC)/Decision  Coordinating  Paper  Procedures 
for  Major  Defense  Systems 

V.  Waivers 

VI.  Exclusions 

VII.  Responsibilities  of  the  Deputy  Director  of  Defense 
Research  and  Engineering,  Test  and  Evaluation 

VIII.  Reporting  Requirements 

IX.  Effective  Date  and  Implementation 
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DODD  5000.3  (Concluded) 


C.  Comments.  While  not  solely  applicable  to  software,  several 
sections  of  this  directive  can  be  used  effectively  to  plan  and/or  monitor 
software  test  and  evaluation.  This  directive  specifies  that  test  and  evalu- 
ation  shall  be  scheduled  in  the  acquisition,  and  that  testing  shall  begin 
early  and  continue  throughout  the  development  cycle.  This  directive  may 
be  used  as  the  justification  for  top-down  testing.  This  directive  is 
implemented,  in  part,  by  AFR  80-14. 
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DODD  5000.  19  - 2 June  1971;  Reprint  with  Change  1-1  June  1973 
POLICIES  FOR  THE  MANAGEMENT  AND  CONTROL  OF  DOD 
INFORMATION  REQUIREMENTS 

A.  Purpose.  This  directive  establishes  uniform  policies  and 
criteria  for  use  in  the  management  and  control  of  Department  of  Defense 
(DOD)  information  requirements  and  resultant  information  systems  that 
may  be  placed  on  DOD  components  and  on  contractors  and  other  external 
agencies  and  organizations.  Its  objective  is  to  assure  optimum  effective- 
ness and  economy  in  the  flow  of  information  and  prevent  the  generation 

of  unauthorized  or  duplicative  information  requirements /systems  by 
requiring  that  each  request  for  information  undergo  an  objective  review 
and  meet  the  criteria  prescribed  in  the  directive. 

B.  Outline  of  Contents 


1.  Purpose  and  Objectives 

2.  Cancellation 

3.  Applicability  and  Scope 

4.  Definitions 

5.  Policy,  Principles,  and  Criteria  for  use  in 
Generating  Information  Requirements 

6.  Responsibilities 

7.  Delegations 

8.  Effective  Date  and  Implementation 
Enclosures: 

1.  References 

2.  Definitions 

3.  OMB  Circular  A-40 

4.  Reviewing  New/Revised  Interagency 
Information  Requirements 

5.  Section  V — Management  of  Federal  Reports 

C.  Comments.  DODD  5000.19  provides  the  policies  for  management 
and  control  of  DOD  information  requirements  and  resultant  information 
systems  as  specified  in  the  directive.  It  addresses  all  information  systems 
as  general  items  and  does  not  single  out  software  systems. 
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DOD  5000.  19-L,  Volume  II  - January  1977 
ACQUISITION  MANAGEMENT  SYSTEMS  AND 
DATA  REQUIREMENTS  CONTROL  LIST  (AMSDL) 

A.  Purpose.  This  document  is  used  by  DOD  contracting  officials 
to  select  (1)  Acquisition  Management  Systems  and  their  source  documents 
and  (2)  Data  Item  Descriptions  (DIDs)  for  application  to  contracts. 

B.  Outline  of  Contents 

Part  I.  Acquisition  Management  Systems  List/Associated  DIDs 
Part  II.  Numerical  Listing  of  DIDs 
Part  III.  Keyword  Index  of  DIDs 

Part  IV.  Cancelled/Superseded  List  (2  sections) 

Part  V.  Appendix/ Explanatory  Information 

C.  Comments.  The  AMSDL  supersedes  DOD  7000. 6M, 

"Acquisition  Management  Systems  List,  11  September  1973,  and  the  DOD 
Authorized  Data  List  (DODADL),  TD-3,  "Index  of  Data  Item  Descriptions , " 
1 June  1976. 
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DODD  5000.29  - 26  April  1976 

MANAGEMENT  OF  COMPUTER  RESOURCES  IN  MAJOR  DEFENSE  SYSTEMS 


Li 


A.  Purpose.  This  DOD  Directive  is  used  by  DOD  component  heads 
for  management  and  control  of  computer  resources  during  the  development, 
acquisition,  deployment,  and  support  of  major  defense  systems. 

B.  Outline  of  Contents 

I.  Purpose 

II.  Applicability  and  Scope 

III.  Duration 

IV.  Definitions 

V.  Policy 

A.  General 

B.  Requirements  Validation  and  Risk  Analysis 

C.  Configuration  Management  of  Computer  Resources 

D.  Computer  Resource  Life  Cycle  Planning 

E.  Support  Software  Deliverables 

F.  Milestone  Definition  and  Attachment  Criteria 

G.  Software  Language  Standardization  and  Control 

VI.  Responsibilities 

VII.  Effective  Date  and  Implementation 
Enclosure  1.  Definitions 

Enclosure  2.  Charter  of  DOD  Management  Steering 
Committee  for  Embedded  Computer 
Resources 

I.  Background 

II.  Scope 

III.  Objectives 

IV.  Activities 
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DODD  5000.29  (Concluded) 


V.  Organization  and  Composition 

VI.  Responsibilities 

VII.  Technical  Panels 

VIII.  Method  of  Operation 

IX.  Definitions 

X.  References 

Enclosure  3.  Memorandum  for  "Technology  Coordinating 
Papers " 

s General  Requirements  for  TCPs 

• Utilization  of  TCPs 

• Content  of  TCPs 

• Management  of  TCP  Process 

• Distribution  of  TCPs 

• Reviews  and  Critiques  of  TCPs 
Enclosure  4.  References 

C.  Comments.  The  Air  Force  implements  this  directive  via 
AFR  800-14,  Volume  II. 
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DODI  5000.31  - 24  November  1976 

INTERIM  LIST  OF  DOD  APPROVED  HIGH  ORDER 

PROGRAMMING  LANGUAGES  (HOL) 


A.  Purpose.  This  DOD  instruction  specifies  the  high  order 
programming  languages  (HOL)  that  are  approved  for  development  of 
software  in  major  defense  systems  acquisition  programs. 

B.  Outline  of  Contents 

I.  Purpose 

II.  Applicability  and  Scope 

III.  HOL  Definition 

IV.  Policy 

V.  Responsibilities 

C.  Comments.  DODI  5000.31  supplements  DODD  5000.29, 
"Management  of  Computer  Resources  in  Major  Defense  Systems.  " It  is 
designed  to  reduce  the  proliferation  of  HOLs  in  defense  systems  and  to 
ensure  control.  It  assigns  to  different  controlling  agencies  the  responsi- 
bility for  maintaining  stability  and  configuration  of  different  HOLs.  The 
approved  HOLs  are  JOVIAL-J3,  JOVIAL-J73,  FORTRAN,  SPL-1,  CMS-2, 
TACPOL,  and  COBOL.  DODI  5000.31  is  implemented  by  AFR  300-10. 


DODI  5010.12  - 5 December  1968 
MANAGEMENT  OF  TECHNICAL  DATA 

A.  Purpose.  This  instruction  establishes  uniform  policies  and 
procedures  for  the  management  and  administration  of  technical  data  con 
tractually  acquired  in  support  of  delivered  equipment. 

B.  Outline  of  Contents 

I.  Purpose 

II.  Cancellation 

III.  Definitions 

IV.  Applicability  and  Scope 

V.  Objectives 

VI.  Policies  and  Procedures 

VII.  Responsibilities 

VIII.  Data  Management  Improvement  Program 

IX.  Effective  Data  and  Implementation 

Enclosures 

C.  Comments.  Mandatory  reading  for  a basic  understanding  of 
deliverable  documentation. 
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DODD  5010.19  - 17  July  1968;  Change  1-6  August  1968 
CONFIGURATION  MANAGEMENT 


A.  Purpose.  This  directive  establishes  the  policies  governing  the 
configuration  management  of  systems  and  equipments. 

B.  Outline  of  Contents 

I.  Purpose 

II.  Applicability 

III.  Definitions 

IV.  Objectives 

V.  Policy 

VI.  Waivers  to  This  Directive 

VII.  Implementation 

VIII.  Effective  Date 

C.  Comments . This  directive  gives  a broad  base  understanding  of 
the  configuration  management  discipline.  Also  supplements  DODI  5010-12. 


DOD  7935. 1-S  - (In  Process) 

AUTOMATED  DATA  SYSTEMS  (ADS)  DOCUMENTATION  STANDARDS 

A.  Purpose.  DOD  Standard  7935. 1-S  will  be  used  as  the  basis  for 
documentation  of  all  ADS  projects,  DOD-wide,  that  are  initiated  after  the 
effective  date  of  the  standard. 

B.  Comments.  This  document  replaces  DOD  4120. 17M,  "Automated 
Data  System  Documentation  Standards  Manual,  " 29  December  1972.  It 
implements  DODI  7935.  1,  "DOD  Automated  Data  Systems  Documentation 
Standards,  " 13  September  1977.  The  standards  in  this  manual  may  be  used 
for  defining  new  DIDs  for  AF  weapon  system  software  procurements  where 
appropriate,  or  may  provide  models  for  revising  or  expanding  standard 

AF  DIDs. 


A.  1.2  AF  Regulations 


AFR  65-3  - 1 July  1974;  Change  1-1  September  1974; 

AFSC  Supplement  1-25  July  1975 
CONFIGURATION  MANAGEMENT 

A.  Purpose.  This  regulation  prescribes  policies  and  guidance  for 
Air  Force  implementation  of  configuration  management.  It  is  part  of  the 
Joint  DOD  Services /Agency  Regulation  on  Configuration  Management. 

B.  Outline  of  Contents 
Chapter  1.  General 

Chapter  2.  Configuration  Identification 
Chapter  3.  Configuration  Control 
Chapter  4.  Configuration  Status  Accounting 
Chapter  5.  Configuration  Audits 

Appendix  A.  Definitions 

Appendix  B.  References 

Appendix  C.  Department  of  the  Army 

Implementing  Instructions 

Appendix  D.  Department  of  the  Navy 

Implementing  Instructions 

Appendix  E.  Marine  Corps  Implementing  Instructions 

Appendix  F.  Department  of  the  Air  Force 
Implementing  Instructions 

Appendix  G.  Defense  Supply  Agency 

Implementing  Instructions 

Appendix  H.  National  Security  Agency 
Implementing  Instructions 

Appendix  I.  Defense  Communications  Agency 
Implementing  Instructions 

Appendix  J.  Defense  Nuclear  Agency 

Implementing  Instructions 
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AFR  73-1  - 30  April  1975;  AFSC  Supplement  1-12  September  1975 
DEFENSE  STANDARDIZATION  PROGRAM  (DSP) 

A.  Purpose.  This  AFR  sets  the  policy  and  establishes  the 
responsibilities  in  carrying  out  the  Defense  Standardization  Program  in 
the  standardization  of  engineering  criteria. 

B.  Outline  of  Contents 

1.  General  Information 
Air  Force  Policy 

Air  Force  Command  Responsibilities 

Channels  of  Communication 
Reporting  on  Standardization 
Delegation  of  Authority 
Supply  of  Forms 
Documentation  Disposition 

C.  Comments.  This  AFR  implements  DOD  4120. 3-M. 
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AFR  74-1  - 4 August  1975 
QUALITY  ASSURANCE  PROGRAM 

A Purpose.  This  AFR  prescribes  the  general  policy  requirements 
and  responsibilities  for  implementing  the  Air  Force  Quality  Assurance 
Program  as  established  in  DODD  4155.1. 

B.  Outline  of  Contents 

1.  Objectives  of  Air  Force  Quality  Assurance  Program 

2.  Explanation  of  Terms 

3.  General  Policy 

4.  Program  Requirements 

5.  HQ  USAF  Responsibilities 

6.  Major  Command  Responsibilities 

7.  Major  Command  Supplements 

C.  Comments.  Gives  good  overview  of  program  quality  objectives. 
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AFR  80-14  - 10  February  1975 

RESEARCH  AND  DEVELOPMENT  TEST  AND  EVALUATION 


A.  Purpose.  This  regulation  outlines  the  policy  and  procedure  for 
managing  the  test  and  evaluation  activities  during  system  development, 
acquisition,  and  deployment.  It  can  be  used  by  contracting  officers  to 
prepare  or  review  software  test  plans,  test  procedures,  and  test  results 
documents . 


B.  Outline  of  Contents.  AFR  80-14  has  the  following  sections: 

A.  Concepts  and  Policies 

B.  Test  and  Evaluation  in  Research,  Exploratory  Development, 
and  Advanced  Development 

C.  Test  and  Evaluation  in  the  Acquisition  Process 

D.  Use  of  Engineering  Services  in  Test  and  Evaluation 

E.  Assignment  of  Responsibilities 

F.  Administration 

C.  Comments.  This  regulation  establishes  the  management  relation- 
ships among  the  implementing  command,  the  Air  Force  Test  and  Evaluation 
Center,  and  the  operating  and  supporting  commands  in  successive  phases 

of  a system's  life  cycle,  from  conceptual  through  deployment  and  opera- 
tion. This  regulation  implements  DOD  Directive  5000.3. 
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AFR  300-2  - 19  August  1977 

MANAGEMENT  OF  THE  USAF  AUTOMATIC  DATA  PROCESSING  PROGRAM 


A.  Purpose.  This  AF  regulation  is  used  by  the  implementing 
command  program  managers  for  the  managing  of  automatic  data  process 
ing  (ADP)  systems,  capabilities,  and  services  and  provides  guidance  for 
ADP  resource  acquisition. 

B . Outline  of  Contents 


Section  A.  Policy 

Section  B.  Responsibilities 

Attachment  1.  List  of  Acronyms  and  Terms 

Attachment  2.  Level  of  Approval  Authorities 

Attachment  3.  Application  of  Policy  Guidance  to 
Management  of  ADP  and  Computer 
Resources 

C.  Comments.  This  19  August  1977  version  of  AFR  300-2 
supersedes  AFR  300-1,  15  November  1974,  and  AFR  300-2,  14  February 
1975. 
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AFR  800-2  (Cl)  - 16  March  1972;  AFSC  Supplement  1-18  October  1974 

Attachments  4 and  5-30  April  1975 
SAMSO  Supplement  1-11  February  1977 
ACQUISITION  MANAGEMENT  - PROGRAM  MANAGEMENT 

A.  Purpose.  This  AF  regulation  is  used  by  implementing  command 
program  managers  for  management  policy  of  Air  Force  acquisition 
programs. 

B.  Outline  of  Contents 


1. 


2. 

3. 


General  Information 

Responsibilities 

Communication 

Attachment  1.  Terms  Explained 

Attachment  2.  Blue  Line  Channel  of  Communications 
Attachment  3.  DODD  5000.1 
Attachment  4.  DODI  5000.2 
Attachment  5.  DODD  5000.26 


C.  Comments.  The  basic  AFR  800-2  (16  March  1972)  included 
Attachments  1,  2,  and  3.  AFR  800-2  (Cl),  30  April  1975,  added  Attach- 
ments 4 and  5.  This  regulation  authorizes  Air  Force  use  of  DOD  policies. 


AFR  800-4  - 10  March  1975;  AFSC/AFLC  Supplement  1-14  August  1975 
TRANSFER  OF  PROGRAM  MANAGEMENT  RESPONSIBILITY 


A.  Purpose.  This  regulation  states  Air  Force  policy  and  assigns 
responsibility  for  the  transfer  of  program  management  responsibility  from 
an  implementation  to  a supporting  command. 

B.  Outline  of  Contents 

1.  Terms  Explained 

2.  Policy 

3.  Responsibilities 

4.  Implementation 


AFR  800-11  - 3 August  1973 
LIFE  CYCLE  COSTING  (LCC) 


A.  Purpose.  This  regulation  outlines  policy  and  methodology  for 
life  cycle  costing  in  the  development,  acquisition,  and  modification  of 
defense  systems  and  subsystems.  This  regulation  may  be  used  by  con- 
tracting officers  during  the  preparation  of  requests  for  proposal  and 
contract  award  decisions. 

B.  Outline  of  Contents 

1.  Explanation  of  Air  Force  Policy  on  LCC 

2.  Terms  Explained 

3.  Use  of  Life  Cycle  Cost 

4.  Formal  Guidance  From  DOD 

5.  Other  Related  Directives 

6.  Responsibilities  Assigned  to  HQ  USAF 

7.  Responsibilities  Assigned  to  HQ  USAF 

8.  Responsibilities  Assigned  to  ATC 

9.  Responsibilities  Assigned  to  Other  Commands 

10.  LCC  Report,  RCS-.SAF-ILd  7201 

11.  How  to  Prepare 

12.  How  to  Submit 

13.  Documentation 

C.  Comments.  The  objective  of  LCC  is  to  consider  ownership  cost 
(operation,  maintenance,  support,  etc. ) as  well  as  development  and 
acquisition  cost,  in  order  to  provide  visibility  of  economic  advantages  of 
the  various  design/development  options  and  acquisition  decisions.  The 
use  of  LCC  is  not  intended  to  make  minimum  cost  the  predominant  decision 
factor,  but  to  ensure  a proper  balance  between  cost  and  system  effectiveness. 


AFR  800-14,  Volume  I - 10  May  1974;  AFSC  Supplement  1 - 8 August  1977 
MANAGEMENT  OF  COMPUTER  RESOURCES  IN  SYSTEMS 

A.  Purpose,  This  AF  regulation  is  used  by  AF  activities  respon- 
sible for  planningT  developing,  acquiring,  supporting,  and  using  systems 
managed  or  acquired  under  AFR  800-2. 

B.  Outline  of  Contents 

Section  A.  General  Information 

1.  Applicability  of  This  Regulation 

2.  Objective  of  This  Regulation 

3.  AF  Policy  on  Management  of  Computer 
Resources  in  Systems 

Section  B.  Assigned  Responsibilities 

4.  Headquarters  USAF 

5.  AF  Systems  Command  (AFSC) 

6.  Program  Manager 

7.  AF  Logistics  Command  (AFLC) 

8.  Using  Activities 

9.  Air  Training  Command  (ATC) 

10.  Air  University 

Attachment  1.  Terms  Explained 

Attachment  2.  Applicability  of  AFRs  Pertaining 
to  ADP  and  Computer  Resources 

C.  Comments.  Volume  I policies  are  implemented  via  Volume  II 
procedures.  AFSC  Supplement  1 to  Volume  I clarifies  the  general  policy 
in  a number  of  areas,  including  Higher  Order  Programming  Languages, 
microprocessors  and  microcomputers,  firmware,  and  the  meaning  oi 
"verification"  and  "validation.  " 


- 96  - 


AFR  800-14,  Volume  II  - 26  September  1975 
ACQUISITION  AND  SUPPORT  PROCEDURES  FOR 
COMPUTER  RESOURCES  IN  SYSTEMS 


A.  Purpose.  This  AF  regulation  is  used  by  AF  activities  imple- 
menting technical  management  of  computer  resources  (both  hardware  and 
software)  for  major  defense  systems. 

B.  Outline  of  Contents 
Chapter  1.  Introduction 

Chapter  2.  Computer  Resources  in  System  Acquisition 
Life  Cycle 

Chapter  3.  Planning 
Chapter  4.  Engineering  Management 
Chapter  5.  Testing  of  Computer  Programs 
Chapter  6.  Configuration  Management 
Chapter  7.  Documentation 

Chapter  8.  Identifying  Contractual  Requirements 

Chapter  9.  Turnover  and  Transfer 

Chapter  10.  Support 

Attachment  1.  Glossary 

Attachment  2.  Bibliography 

Figure  2-1.  Computer  Program  Life  Cycle 

Figure  7-1.  Data  Related  to  the  Computer 
Program  Life  Cycle 

Table  7-1.  Standard  Contract  Data  Items 

C.  Comments.  Volume  II  of  AFR  800-14  implements  Volume  I 
policies. 

D.  Cautions.  The  following  parts  of  Volume  II  contain  statements 
that  are  misleading  or  erroneous: 


I 
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AFR  800-14  (Concluded) 


(1)  Paragraph  2-5a  (page  2-2)  says: 

"For  computer  programs,  the  preliminary 
design  . . . should  be  contained  in  the  develop- 
ment specifications  and  become  the  basis  for 
the  PDR  of  the  computer  program.  " 

Locating  the  preliminary  design  in  the  development  specifi- 
cation instead  of  the  product  specification  appears  to  be  an 
editorial  error.  At  least  it  contradicts  paragraph  4-9c 
(page  4-4),  which  in  discussing  PDRs  says: 

"The  design  approach  for  computer  programs 
is  contained  in  portions  of  the  product 
specification.  " 

The  following  sentence  in  paragraph  4-9c  lists  as  the 
contents  of  the  initial  portion  of  the  product  specification 
the  same  items  that  paragraph  2 -5a  says  should  be  in  the 
development  specification. 

(2)  Similarly,  paragraph  2-8a  (page  2-3)  says  that  the 

"...  authenticated  development  specification 
forms  the  baseline  from  which  the  design 
phase  [i.e.,  the  "detailed"  design  phase, 
which  follows  PDR]  initiates.  " 

This  is  true  if  the  baseline  referred  to  is  the  "requirements" 
baseline,  but  not  if  it  is  the  "design"  baseline.  The  preli- 
minary "code-to"  product  specification,  which  should  be  the 
major  subject  of  review  at  PDR  according  to  paragraph  4-9c 
(discussed  above),  is  not  mentioned  at  all  in  paragraph  2-8a. 
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AFR  800-19  - 27  May  1975 
SYSTEM  OR  EQUIPMENT  TURNOVER 

A.  Purpose.  This  AFR  establishes  policy  for  the  turnover  to  an 
operating  command  of  systems  or  equipments  developed  under  the  program 
management  concept. 

B.  Outline  of  Contents 

1.  Terms  Explained 

2.  Air  Force  Policy 

3.  Responsibilities 

4.  Turnover  Documentation 
Attachment  1 

C.  Comments . This  AFR  addresses  computer  resources  in 
Attachment  1.  Supplements  AFR  800-4. 
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A.  1.3  AFSC  Pamphlets 
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A. 1.4  SAMSO  Pamphlets/Regulations 
SAMSOP  74-2  - 1 September  1976 

CONTRACTOR  SOFTWARE  QUALITY  ASSURANCE  EVALUATION  GUIDE 

A.  Purpose.  This  document  is  intended  for  use  as  a guide  to 
Government  personnel  responsible  for  the  evaluation  of  a contractor's 
software  quality  program  when  MIL-S-52779  (AD)  is  applied  to  the 
contract. 

B . Outline  of  Contents 

1.  Scope 

1.1  Applicability 

1.2  Contractual  Intent 

1.3  Relation  to  Other  Requirements 

2.  Applicable  Documents 

3.  Requirements 

3.1  Software  QA  Program 

3.2  Software  QA  Program  Requirements 

3.2.1  Initial  Quality  Planning 

3.2.2  Configuration  Management 

3.2.3  Testing 

3.2.4  Corrective  Action 

3.2.5  Library  Controls 

3.2.6  Computer  Program  Design 

3.2.7  Software  Documentation 

3.2.8  Reviews  and  Audits 

3.2.9  Tools,  Techniques,  and  Methodologies 

3.3  Subcontractor  Control 

4.  Responsibilities 
4.  1 Contractor 

4.2  Government  Review  at  Contractor,  Subcontractor, 
Vendor  Facilities 

5.  Preparation  for  Delivery 

6.  Notes 

C.  Comments.  This  evaluation  plan  should  apply  to  all  aspects  of  a 
contractor's  program.  The  pamphlet  emphasizes  the  planning  and  execu- 
tion of  a comprehensive  software  quality  program. 
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SAMSOR  70-2  - 15  August  1975 
REQUEST  FOR  PROPOSAL  POLICY 


A.  Purpose.  This  SAMSO  regulation  establishes  the  responsibilities 
and  procedures  for  issuance  of  competitive  and  single-source  RFPs. 

B.  Outline  of  Contents 

1.  Policy 

2.  Responsibilities 

3.  Procedures 

Attachment  i.  Executive  Management  Summary  Letter 
Attachment  2.  Proposal  Preparation  Instructions 
Attachment  3.  Evaluation  Factors  for  Award 
Attachment  4.  Sample  Request  for  Proposal 
Attachment  5.  Sample  Study  Contract  RFP 

C.  Comments.  A very  useful  document.  The  amount  and  format 
of  the  information  is  such  that  it  is  easily  understood  for  practical 
implementation. 
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A .  1 . 5 AFSC  Design  Handbooks 
AFSC  DH  4-2  - 10  April  1971 

ELECTRONIC  SYSTEMS  TEST  AND  EVALUATION 

A.  Purpose.  This  handbook  documents  Air  Force  technical 
knowledge  in  the  area  of  electronic  systems  test  and  evaluation,  and 
specifically  discusses  computer  program  subsystem  test  and  evaluation 
in  Chapter  5.  This  handbook  can  be  used  by  contracting  officers  to  pre- 
pare or  review  software  test  plans,  test  procedures,  and  test  result 
documents. 

E . Outline  of  Contents 

1.  General 

2.  Overview  of  Electronic  Systems  Testing 

3.  Test  and  Evaluation  Functional  Flow  Diagram 

4.  Hardware  Subsystem  Test  and  Evaluation 

5.  Computer  Program  Subsystem  Test  and  Evaluation 

A.  Test  Planning 

B.  Test  Tools 

C.  Computer  Program  Test  Phases 

D.  Special  Applications 

6.  Facility  Subsystem  Test  and  Evaluation 

7.  Personnel  Subsystem  Test  and  Evaluation 

8.  Critical  Component  Test  and  Evaluation 

9.  Inter  system/ Intrasystem  Integration  Test  and  Evaluation 

10.  System  Test  and  Evaluation 

11.  Logistics  Evaluation 

12.  Test  Hazards  and  Safety 

13.  Economics  of  Testing 

C.  Comments.  This  handbook  contains  criteria  and  guidance  for 
the  design  of  test  and  evaluation  programs  for  Air  Force  systems  and 
equipment.  It  is  directed  towards  the  testing  and  evaluation  processes  as 
set  forth  in  AFR  80-14. 
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A. 1.6  Navy  Instructions 
NAVMATINST  4130.  2A  - 19  July  1976 

CONFIGURATION  MANAGEMENT  OF  COMPUTER  SOFTWARE 
ASSOCIATED  WITH  TACTICAL  DIGITAL  SYSTEMS  AND  OTHER 
TECHNICAL  COMPUTER  SYSTEMS 

A.  Purpose.  This  instruction  defines  the  responsibilities  of 
Naval  Systems  Commanders  and  Project  Managers  for  configuration 
management  of  computer  software  associated  with  tactical  digital  systems 
and  other  technical  computer  systems  developed  and/or  maintained  by  the 
Naval  Materiel  Command.  Tactical  Digital  Systems  are  fleet  systems  that 
employ  digital  processing  techniques  that  contribute  directly  to  perform- 
ance in  the  areas  of  command  and  control,  navigation,  communicat’on, 
weapons  delivery,  fire  control,  sensor  surveillance,  and  electronic 
warfare. 

B.  Outline  of  Contents 

1.  Purpose 

2.  Cancellation 

3.  Applicability 

4.  Definitions 

5.  Background 

6.  Policy 

7.  Action 

8.  Implementation 

C.  Comments.  NAVMATINST  4130.  2A  points  out  the  need  for 
configuration  management  during  the  life  cycle  of  computer  software 
associated  with  Tactical  Digital  Systems  and  other  Technical  Computer 
Systems  and  puts  the  responsibility  of  implementation  on  Naval  Systems 
Commanders  and  Project  Managers.  (NAVMATINST  4130.  2A  should  not 
be  confused  with  NAVMATINST  4130. 1A,  which  is  the  Navy  portion  of  the 
Joint  DOD  Services/Agency  Regulation  on  Configuration  Management. 

See  the  summary  for  AFR  65-3.) 
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SECNAVINST  3560.1  - 8 August  1974 

TACTICAL  DIGITAL  SYSTEMS  DOCUMENTATION  STANDARDS 


A.  Purpose.  This  Navy  document  is  used  by  the  procuring  agency 
to  select  documentation  for  tactical  systems  software  development.  It 
identifies  and  describes  documents  that  support  the  development  and 
maintenance  of  tactical  systems  software. 

B.  Outline  of  Contents 

1.  Introduction 

1 . 1 Purpose 

1.2  Scope 

2.  Applicable  Documents 

3.  Document  Description 

Part  I.  Operational  Requirement  Document  Types 
Part  II.  Technical  Development  Document  Types 
Part  III.  Test  Document  Types 
Part  IV.  User-Narrative  Document  Types 
Part  V.  Format 

C.  Comments.  SECNAVINST  3560.  1 is  a very  detailed  document. 
It  provides  the  user  with  the  precise  format  and  preparation  instructions 
necessary  for  specifications,  plans,  and  procedures  relative  to  tactical 
systems  computer  program  development.  It  does  not  prescribe  which 
documents  to  use,  but  does  suggest  applications.  It  contains  formats  for 
data  base  documents  and  interface  control  specifications,  which  are  not 
included  in  MIL-STD-490  or  MIL-STD-483.  The  standards  in  this  manual 
may  be  used  for  defining  new  DIDs  for  AF  weapon  system  software  pro- 
curements where  appropriate,  or  may  provide  models  for  revising  or 
expanding  standard  AF  DIDs. 
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A.  1.7  Army  (POD)  Regulations 

AR  70-37  - Undated  Draft 
CONFIGURATION  MANAGEMENT 

A.  Purpose.  This  regulation  prescribes  uniform  policies  and 
guidance  for  the  Army  for  implementation  of  configuration  management. 

B.  Comments.  AR  70-37  is  an  appendix  to  DODD-XXXX.X,  dated 
1 July  1977,  and  constitutes  the  Army  implementing  instructions  for 

the  DOD  directive.  It  is  in  draft  form,  but  it  is  presumed  that  in  its  final 
form,  it  will  supplement  information  in  the  DOD  directive,  spelling  out 
specific  responsibilities  for  different  commands  of  the  Army.  Previous 
issues  of  the  regulation  described  how  configuration  management  is 
performed. 


A. 1.8  Technical  Orders 


TO-OO-5-2  - 20  August  1973;  Change  1-15  February  1974 
TECHNICAL  ORDER  DISTRIBUTION  SYSTEM 

A.  Purpose.  This  document  explains  in  detail  the  distribution 
policy,  numerical  indexing  method,  technical  order  codes,  and  revisions 
of  technical  orders  for  all  USAF  commands. 

B.  Outline  of  Contents 
Section  1.  Introduction 
Section  2.  Responsibilities 

Section  3.  Numerical  Index  and  Requirement  Table 

Section  4.  Technical  Order  Codes,  Files,  and  Requirements 

Section  5.  Initial  Distribution  Requirements 

Section  6.  Requisitioning 

Section  7.  Distribution 

Section  8.  Special  Weapons  Technical  Orders 

Section  9.  Military  Assistance  Program 

Section  10.  List  of  Applicable  Technical  Order  Distribution 

Section  11.  Special  Purpose  Distribution  Codes 

Section  12.  Interservice  Distribution  of  Technical  Publications 

Section  13.  Special  Distribution 

Section  14.  Distribution  of  Non-Nuclear  Munitions 
Specialized  Technical  Orders 

Section  15.  Interservice  Technical  Information  Exchange 
Service  (ITIES) 

Section  16.  TO  Requirements  and  Distribution  Checklist 

C.  Comments.  The  Air  Force  Technical  Order  System  is  a technical 
service  specifically  designed  to  support  trained  specialists  in  each  of  the 
commands  and  in  other  authorized  using  activities. 
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A.  2 COMPLIANCE  DOCUMENTS 

A. 2.1  Military  Specifications 

MIL-Q-9858A  - 16  December  1963 
QUALITY  PROGRAM  REQUIREMENTS 

A.  Purpose.  This  military  specification  applies  to  supplies  and 
services  for  which  the  requirement  of  MIL-I-45208,  "Inspection  System 
Requirements,  " are  inadequate  to  provide  needed  quality  assurance.  This 
specification  requires  the  contractor  to  establish  a quality  program  to 
assure  compliance  with  contractual  requirements.  MIL-Q-9858A  is  man- 
datory for  use  by  the  Air  Force,  Army,  Navy,  and  Defense  Supply  Agency. 

B.  Outline  of  Contents 

1.  Scope 

2.  Superseding,  Supplementation,  and  Ordering 
2.1  Applicable  Documents 

3.  Quality  Program  Management 

4.  Facilities  and  Standards 

5.  Control  of  Purchases 

6.  Manufacturing  Control 

7.  Coordinated  Government/Contractor  Actions 


8.  Notes 

C.  Comments.  Although  MIL-Q-9858A  is  hardware-oriented,  it 
contains  some  general  quality  assurance  provisions  that  are  not  included 
in  MIL-S-52779  (AD)  and  that  can  be  applied  to  software  procurements. 

These  provisions  include  subsection  3.1  on  quality  program  management  ) 

organization,  3.2  on  initial  quality  planning,  3.4  on  quality  program 
records,  and  6.7  on  indication  of  inspection  status  (could  be  applied  to 
software  library  control). 
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MIL-S-52779  (AD)  - 5 April  1974 

SOFTWARE  QUALITY  ASSURANCE  PROGRAM  REQUIREMENTS 


A.  Purpose.  This  military  specification  is  applied  by  DOD 
contracting  officials  to  the  acquisition  of  computer  programs  and  related 
documentation  whether  acquisition  involves  software  alone  or  software  as 
part  of  a system  or  subsystem. 

B.  Outline  of  Contents 

1.  Scope 

1.1  Applicability 

1.2  Contractual  Intent 

1.3  Relation  to  Other  Contract  Requirements 

2.  Applicable  Documents 

2.1  Amendments  and  Revisions 

2.2  Ordering  Government  Documents 

3.  Requirements 

3.1  Software  QA  Program 

3.2  Software  QA  Program  Requirements 

3.2.1  Work  Tasking  and  Authorization  Procedures 

3.2.2  Configuration  Management 

3.2.3  Testing 

3.2.4  Corrective  Action 

3.2.5  Libra- y Controls 

3.2.6  Computer  Program  Design 

3.2.7  Software  Documentation 

3.2.8  Reviews  and  Audits 

3.2.9  Tools,  Techniques,  and  Methodologies 

3.3  Subcontractor  Control 

4.  Responsibilities 

4. 1 Contractor 

4.2  Government  Review  at  Contractor,  Subcontractor, 
or  Vendor  Facilities 


■ ■ " — ■ — I 


Mil. -S- 52779  (AD)  (Concluded) 

5.  Preparation  for  Delivery  (NA) 

6.  Notes 

6.  1 Intended  Use 
6.2  Ordering  Data 

6.2.1  Procurement  Requirements 

6.2.2  Contract  Data  Requirements 

C.  Comments.  MI1.-S-52779  (AD)  requires  the  establishment  and 
implementation  of  a software  quality  assurance  program  by  the  contractor. 
Section  ^ defines  the  specific  areas  that  the  contractor's  software  QA 
program  must  address.  It  is  important  that  Section  i be  tailored  to  each 
QA  program. 
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MIL-S-63490  - 30  October  1968 
SPECIFICATIONS,  TYPES  AND  FORMS 

A.  Purpose.  The  specification  prescribes  general  requirements 
for  the  preparation  of  specifications  for  the  departments  and  agencies  of 
the  DOD.  It  applies  to  specifications  acquired  from  industry  by  contract 
or  order  and  to  equivalent  acquisition  from  government  sources. 

B.  Outline  of  Contents 

1.  Scope 

2.  Applicable  Documents 

3.  Requirements 

3.1  General 

3.2  Types  of  Specifications 

3.3  Forms  of  Specifications 

3.4  Numbering  of  Specifications 

3.5  Material 


4.  Quality  Assurance  Provision 


5.  Preparation  for  Delivery 

6.  Notes 


C.  Comments.  MIL-S-83490  defines  in  detail  what  the  different 
types  of  specifications  are  as  well  as  the  different  forms,  i.e..  Form  la, 
lb,  etc.  MIL-STD-490  is  related  to  this  specification  in  that  it  describes 
the  detailed  format  for  each  of  the  types  defined  in  MIL-S-83490. 
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MIL-STD-480  - 30  October  1968 

CONFIGURATION  CONTROL  - ENGINEERING  CHANGES, 
DEVIATIONS,  AND  WAIVERS 


I 


A.  Purpose.  This  DOD  standard  establishes  the  criteria  and  uniform 
practices  for  proposing,  justifying,  generating,  and  approving  engineering 
changes,  waivers,  and  deviations.  It  also  provides  requirements  for  con- 
figuration control  with  uniform  terminology  and  definitions. 

B.  Outline  of  Contents 


1.  Scope 

2.  Referenced  Documents 

3.  Definitions  (Appendix  E) 

4.  Requirements  for  Engineering  Changes 
4.  1 General 

4.2  Classification 

4.3  Engineering  Change  Justification 

4.4  Class  I ECP  Types 

4.  5 Class  I Engineering  Change  Priorities 
4.6  Format 
4.  7 Preparation 

4.8  Submittal 

4.9  Approval  and  Review 

4.10  Revision  of  ECPs 

4.11  Correction  of  ECPs 


5.  Requirements  for  Notices  of  Revision 

6.  Additional  Requirements  for  Facility  Construction  Contracts 

7 Requirements  for  Deviations 

8.  Requirements  for  Waivers 

10  Appendix  A.  Instructions  for  Preparation  of  ECP 

80  Appendix  B.  Instructions  for  the  Preparation  of 

Request  for  Deviation 

90  Appendix  C.  Instructions  for  the  Preparation  of 
Request  lor  Waiver 

110  Appendix  E.  Definitions 
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MIL-STD-480  (Concluded) 

C.  Comments.  MIL-STD-480  applies  requirements  for  technical, 
fiscal,  and  logistic  information  relative  to  proposed  changes  during 
engineering/operational  systems  development,  production  and  the  opera- 
tional CI/CPCI  life  cycle.  It  may  also  be  used  for  advanced  development 
programs  to  control  contractually  imposed  functional  characteristics  and 
design  constraints.  Additional  latitude  is  provided  by  MIL-STD-480  in 
that  it  may  also  be  applied  to  facility  construction  contract  drawings  and 
specifications  during  construction  and  operation  period  on  an  as-required 
basis  due  to  operational  weapons,  systems,  and  equipment  changes. 
MIL-STD-480  does  not  specifically  address  itself  to  software,  but  its 
techniques  are  required  by  the  military  standards  used  to  control  and 
identify  software  (e.g.,  MIL-STD-483,  490,  and  1521A). 


MIL -STD-481  A - 18  October  1972 

CONFIGURATION  CONTROL  - ENGINEERING  CHANGES,  DEVIATIONS, 
AND  WAIVERS  (SHORT  FORM) 


A.  Purpose.  This  standard  prescribes  requirements  for  the 
preparation  and  submittal  of  an  abbreviated  engineering  change  proposal 
as  well  as  deviations  and  waivers.  This  standard  is  intended  for  use  in 
contracts  involving  procurement  of  multi-application  items  or  items  for 
which  the  prescribed  detail  design  was  not  developed  by  the  contractor. 

B.  Outline  of  Contents 

1.  Scope 

2.  Referenced  Documents 

3.  Definitions 

4.  Requirements  for  Engineering  Changes 

5.  Requirements  for  Deviations 

6.  Requirements  for  Waivers 

10.  Appendix  A.  Instructions  for  the  Preparation  of  ECP 

20.  Appendix  B.  Instructions  for  the  Preparation  of 

Request  for  Deviation 

30.  Appendix  C.  Instructions  for  the  Preparation  of 
Request  for  Waiver 

C.  Comments.  MIL-STD-481A  supplements  MIL-STD-480.  It 
provides  a simplified  method  of  configuration  control,  but  has  a very 
limited  description  of  the  effect  on  interfaces  and  logistic  support.  Where 
a detailed  analysis  and  description  of  an  engineering  change  is  desired, 
MIL-STD-480  should  be  used.  MIL-STD-481A  does  not  specifically 
address  itself  to  software,  but  its  techniques  may  be  applied  to  change 
management  of  software. 
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MIL -STD- 482  A - 1 April  1974 

CONFIGURATION  STATUS  ACCOUNTING  DATA  ELEMENTS 
AND  RELATED  FEATURES 

A.  Purpose.  This  standard  provides  a comprehensive  listing  of 
standard  data  elements  foi  tailoring  the  selection  of  information  to  be 
recorded  and  reported  to  identify  CIs  and  CPCIs  and  determine  the  status 
of  change  proposal  and  change  implementation  status  of  those  CIs  and 
CPCIs. 

B.  Outline  of  Contents 

1.  Scope 

2.  Referenced  Documents 

3.  Definitions 

4.  General  Requirements 

5.  Detailed  Requirements 

6.  Notes 

Appendix  I.  Index  of  Configuration  Status  Accounting 
Data  Elements  and  Data  Use  Identifiers 

Appendix  II.  Standard  Data  Elements  and  Related  Features 

Appendix  III.  Status  Accounting  Samples 

C.  Comments.  MIL-STD-482A  supplements  the  status  accounting 
requirements  of  MIL-STD-480,  481A,  483,  490,  and  1521A.  It  establishes 
data  elements  to  be  used  as  the  content  of  configuration  status  accounting 
reports.  It  does,  not  prescribe  which  data  elements  to  use  nor  does  it 
specify  the  repdrt  format  or  frequency.  Such  requirements  are  specified 
on  a case-by-case  basis  by  the  managing  organization. 
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MIL-STD-483  (USAF)  - 31  December  1970 

CONFIGURATION  MANAGEMENT  PRACTICES  FOR  SYSTEMS, 
EQUIPMENT,  MUNITIONS,  AND  COMPUTER  PROGRAMS 


A.  Purpose.  This  Air  Force  standard  is  used  by  procurement 
officials  and  their  staffs  to  apply  configuration  management  requirements 
(including  major  baseline  specifications)  to  contracts.  As  the  title  indi- 
cates, this  standard  can  be  applied  to  many  other  items  besides  computer 
programs . 

B.  Outline  of  Contents 


1.  Scope 

2.  Referenced  Documents 


3. 


4. 

5. 


Requirements 

3.1  Introduction 

3.2  Baseline  Management 

3.3  System  Engineering  and  Interface  Control 

3.4  Configuration  Identification 

3.5  Specification  Maintenance 

3.6  Configuration  Item  Identification 

3.7  Engineering  Release  Requirements  and  Correlation 
of  Manufactured  Products 

3.8  System  Allocation  Document 

3.9  Configuration  Audits 

3.10  Engineering  Changes  {Equipment/Munitions) 

3.10.1  Engineering  Changes  (Computer  Programs) 

3.11  Reporting  the  Accomplishment  of  Updating/ 

Retrofit  Changes 

3.12  Configuration  Management  Records/Reports 
Data 

Definitions 


10.  Appendix  I. 
20.  Appendix  II. 
30.  Appendix  III. 

40.  Appendix  IV. 


Configuration  Management  Plan 
Interface  Control 

System  Specification/System  Segment 
Specification  (Supplements  MIL-STD-490) 

Addendum  to  Configuration  Item 
Specification 
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MIL-STD-483  (USAF)  (Concluded) 
50.  Appendix  V. 


Inventory  Item  Specification  (Not  appli- 


u. 


80.  Appendix  VIII.  Specification  and  Support  Documenta- 
tion Maintenance,  Computer  Program 
(Includes  preparation  of  specification 
change  notices  (SCNs),  computer  con- 
figuration indexes,  configuration  item 
development  records,  computer  pro- 
gram change  status  listings,  and 
version  description  documents  (VDDs).) 

90.  Appendix  IX.  Document  and  Item  Identification 

Numbering  and  Marking 

100.  Appendix  X.  Engineering  Release  Records  and 

Correlation  of  Manufactured  Products 


110.  Appendix  XI.  System  Allocation  Document 

120.  Appendix  XII.  Configuration  Audits  (FCA,  PCA,  FQR) 

130.  Appendix  XIII.  Engineering  Changes  (equipment/ 

munitions) 


140.  Appendix  XIV.  Engineering  Changes  (computer 

programs)  (Supplements  MIL-STD-480) 

150.  Appendix  XV.  Reporting  the  Accompl ishment  of 

Updating/Retrolit  Changes 

C.  Comments.  MtL-STD-483  supplements  MIL-STD-480,  481, 

482,  and  490  in  that  portions  of  MIL-STD-483  specifically  address  require- 
ments of  software  not  found  in  MIL-STD-480,  481,  and  490.  These  include: 

1.  Computer  program  specification  preparation  instructions 

2.  Specification  and  support  documentation  maintenance  for 
computer  programs 

3.  Formatting  and  processing  of  changes  to  computer  programs 

4.  Configuration  audit  objectives  for  computer  programs. 

MIL-STD-483  also  includes  all  the  requirements  necessary  for  total  configu 
ration  control  and  baseline  management  on  a large  USAF  software  contract. 
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MIL-STD-490  - 30  October  1968;  Notice  1-1  February  1969; 

Notice  2-18  May  1972 

SPECIFICATION  PRACTICES 

A.  Purpose.  MIL-STD-490  establishes  the  format  and  contents  of 
specifications  for  project-peculiar  items,  processes,  and  materials.  It 
establishes  uniform  practices  for  specification  preparation,  ensures  the 
inclusion  of  essential  requirements,  and  aids  in  the  use  and  analysis  of 
specification  content. 

B.  Outline  of  Contents 

1.  Scope 

2.  Referenced  Documents 

3.  Requirements 

3.1  Introduction 

3.2  Style,  Format,  and  Identification  of  Specifications 

3.3  Changes  and  Revisions 

4.  General  Requirements  for  Sections  of  Specifications 

4.1  Section  1.  Scope 

4.2  Section  2.  Applicable  Documents 

4.3  Section  3.  Requirements 

4.4  Section  4.  Quality  Assurance  Provisions 

4.5  Section  5.  Preparation  for  Delivery 

4.6  Section  6.  Notes 
4.  7 Appendix  and  Index 

5.  Detail  Requirements 


10. 

Appendix  I. 

Type  A,  System  Specification 

20. 

Appendix  II. 

Type  Bl,  Prime  Item  Development 
Specification 

30. 

Appendix  III. 

Type  B2,  Critical  Item  Development 
Specification 

40. 

Appendix  IV. 

Type  B3,  Non-Complex  Item 
Development  Specification 

50. 

Appendix  V. 

Type  B4,  Facility  or  Strip 
Development  Specification 

60. 

Appendix  VI. 

Type  B5,  Computer  Program 
Development  Specification 
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MIL-STD-490  (Concluded)' 


70.  Appendix  VII. 

80.  Appendix  V III. 

90.  Appendix  IX. 

100.  Appendix  X. 

110.  Appendix  XI. 

120.  Appendix  XII. 
130.  Appendix  XIII. 

140.  Appendix  XIV. 
150.  Appendix  XV. 


Type  Cla,  Prime  Item  Product 
Function  Specification 

Type  Clb,  Prime  Item  Product 
Fabrication  Specification 

Type  C2a,  Critical  Item  Product 
Function  Specification 

Type  C2b,  Critical  Item  Product 
Fabrication  Specification 

Type  C3,  Non-Complex  Item  Product 
Fabrication  Specification 

Type  C4,  Inventory  Item  Specification 

Type  C5,  Computer  Program  Product 
Specification 

Type  D,  Process  Specification 
Type  E,  Material  Specification 


C.  Comments.  The  Type  B5  and  Type  C5  specifications  apply 
directly  to  software.  MIL-STD-490  is  a standard  that  applies  to  all 
services.  Revision  A to  this  document  is  in  preparation.  It  is  intended 
to  have  the  A revision  resolve  the  discrepancies  that  exist  now  between 
MIL-STD-490  and  MIL-STD-483. 


MIL-STD-499A  (USAF)  - 1 M.iy  1<?74 
ENGINEERING  MANAGEMENT 


A#  Purpo se . This  standard  is  used  as  a guide  by  military  agencies 
and  contractors  to  plan,  conduct,  and  manage  system  engineering  activities 

B . Outline  of  Contents 

1.  Scope 

2.  Referenced  Documents 

3.  Definitions 

3.1  Engineering  Management 

3.2  Technical  Program  Planning  and  Control 

3.3  System  Engineering  Process 

3.4  Engineering  Specialty  Integration 

3.5  Technical  Performance  Measurement 

4.  General  C riteria 

5.  Detailed  Requirements 

5.1  System  Engineering  Management  Plan  (SEMP1 

5.1.1  Contractual  Provisions 

5.1.2  Non-Contractual  Provisions 

5.2  Review  of  Contractor's  Engineering  Management 

6.  Notes 

b.l  Relationship  of  Technical  Program  Planning  lo 
Cost  and  Schedule  Planning 

6.2  Relationship  of  Technical  Performance  Measurement 
(TPM)  to  Cost  and  Schedule  Performance  Measurement 

6.3  Relationship  of  Integrated  Logistics  Support  (ILS) 
to  System  Engineering 

6.4  Minimum  Documentation 

6 . 5 Data 


I' 
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MIL- STD -499 A (USAF)  (Concluded) 


Appendix  A, 

Task  Statements 

10.1  Technical  Program  Planning  and  Control 

10.1.1 

Development  of  Contract  Work  Break- 
down Structure  (CWBS)  and  Specification 
Tree 

10.1.2 

Program  Risk  Analysis 

10.1.3 

System  Test  Planning 

10. 1.4 

Decision  and  Control  Process 

10.  1.5 

Technical  Performance  Measurement 
(TPM) 

10.1.6 

Technical  Reviews 

10. 1. 7 

Subcontractor/Vendor  Reviews 

10.  1.8 

Work  Authorization 

10.1.9 

Documentation  Control 

10.2  System 

Engineering  Process 

10.2.1 

Mission  Requirements  Analysis 

10.2.2 

Functional  Analysis 

10.2.3 

Allocation 

10.2.4 

Synthesis 

10.2.5 

Logistic  Engineering 

10.2.6 

Life  Cycle  Cost  Analysis 

10.2.7 

Optimization 

10.2. 8 

Production  Engineering  Analysis 

10.2.9 

Generation  of  Specifications 

C.  Comments.  This  standard  emphasizes  the  tailoring  of  engineering 
tasks  to  each  particular  program,  and  calls  for  all  engineering  tasks  to 
be  performed  as  a single  total  integrated  engineering  effort.  It  contains 
the  requirements  for  preparation  of  a System  Engineering  Management 
Plan  (SEMP)  and  provides  criteria  for  the  Program  Manager  to  evaluate 
individual  program  engineering  planning  and  output.  The  appendix  includes 
task  statements  that  can  be  tailored  to  particular  programs  as  specific 
contractual  requirements.  The  system  qualities  that  this  specification 
seeks  to  enhance,  such  as  reliability,  maintainability,  and  reduced  life 
cycle  cost,  are  not  as  readily  achievable  for  software  procurements  as 
for  hardware.  The  actual  methodologies  for  this  purpose  are  not  well 
defined  and  the  guidance  documentation  is  meager. 
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MIL -STD -881 A - 25  April  1975 

”'oRK  BREAKDOWN  STRUCTURES  FOR  DEFENSE  MATERIAL  ITEMS 


■A*  Purpose.  This  standard  defines  all  the  requirements  necessary 
for  preparation  and  utilization  of  work  breakdown  structures  (WBSs). 

B.  Outline  of  Contents 

1.  Scope 

1 . 1 Purpose 

1.2  Application 

2.  Referenced  Documents 

3.  Definitions 

3.4  Work  Breakdown  Structure 

3.5  Summary  Work  Breakdown  Structure 

3.6  Project  Summary  Work  Breakdown  Structure 

3.7  Contract  Work  Breakdown  Structure 

3.8  Project  Work  Breakdown  Structure 

3.9  Work  Breakdown  Stiucture 

4.  General  Requirements 

5.  Detailed  Requirements 

5.1.2  Electronics  Systems 

5.2  Project  Summary  Work  Breakdown  Structure 

5.3  Contract  Work  Breakdown  Structure 

5.4  Preparation  of  Project  Work  Breakdown  Structure 

Appendices 

C.  Comments.  Avionics-oriented  WBS  elements  are  identified 
through  Level  3 (aircraft  system),  Appendix  C (missile  system),  and 
Appendix  F (space  system).  Each  of  these  appendices  is  currently  deficient 
with  respect  to  identifying  on-board  data  processing  and  software  as  a 
Level  3 WBS  element,  although  data  processing  appears  at  Level  3 within 
the  ground  support  subsystem.  Work  is  currently  underway  to  revise 
MIL -STD -881 A to  accommodate  embedded  computer  systems,  but  in  the 
meantime  Air  Force  Program  Offices  must  add  on-board  data  processing 
and  software  as  a specific  Level  3 WBS  element  to  assure  visibility  into 
avionics  software  management. 


MIL- STD- 1521 A (USAF)  - 1 June  1976 

TECHNICAL  REVIEWS  AND  AUDITS  FOR  SYSTEMS,  EQUIPMENTS, 
AND  COMPUTER  PROGRAMS 


A.  Purpose.  This  standard  gives  the  requirements  for  the  conduct 
of  the  following  seven  milestone  events:  systems  requirements  review 
(SRR),  system  design  review  (SDR),  preliminary  design  review  (PDR), 
critical  design  review  (CDR),  functional  configuration  audit  (FCA),  physical 
configuration  audit  (PCA),  and  formal  qualification  review  (FQR).  This 
standard  is  used  by  contracting  offices  throughout  the  acquisition  life 
cycle  for  the  purpose  of  monitoring  program  activities  to  ensure  con- 
tractual compliance. 

B.  Outline  of  Contents 

1.  Scope 

I 

1.1  Purpose 

1.2  Classification 

1 . 3 Application 

2.  Referenced  Documents 

I 

I 

3.  Definitions 

3. 1 System  Requirements  Review  (SRR) 

3.2  System  Design  Review  (SDR) 

3.3  Preliminary  Design  Review  (PDR) 

3.4  Critical  Design  Review  (CDR) 

3.  5 Functional  Configuration  Audit  (FCA) 

3.6  Physical  Configuration  Audit  (PCA) 

3.7  Formal  Qualification  Review  (FQA) 

4.  General  Requirements 

4.1  Contractor  Participation  and  Responsibilities 

4.1.1  Subcontractors  and  Suppliers 

4.1.2  Location 

4.1.3  Contractor  Requirements 

4.2  Procuring  Activity  Participation 

4.3  Sample  Forms 


. R 
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MIL  - STD- 1 521 A (USAF)  (Concluded) 

5.  Detailed  Requirements 

5.1  (Reference  the  appendices  for  the  detailed 
requirements) 

6.  Notes 

10.  Appendix  A.  System  Requirements  Review  (SRR) 

20.  Appendix  B.  System  Design  Review  (SDR) 

30.  Appendix  C.  Preliminary  Design  Review  (PDR) 

40.  Appendix  D.  Critical  Design  Review  (CDR) 

50.  Appendix  E.  Functional  Configuration  Audit  (FCA) 

60.  Appendix  F.  Physical  Configuration  Audit  (PCA) 

70.  Appendix  G.  Formal  Qualification  Review  (FQR) 

C.  Comments.  This  standard  identifies  contractor  and  Government 
responsibilities  in  the  conduct  of  a review  or  audit,  and  outlines  the  mini- 
mum content  of  information  to  be  presented.  The  reviews  and  actions 
connected  with  the  reviews  are  defined.  A flowchart  of  program  activities 
showing  when  the  reviews  occur  in  relation  to  other  program  activities 
is  given.  (The  Reviews  and  Audits  Guidebook  contains  guidelines  for 
interpretation  and  use  of  MIL- STD-1 521  A. ) 


D.  Caution.  Figure  1,  the  flowchart  of  program  activity,  shows 
the  draft  product  specification  as  being  an  input  to  the  CDR  but  not  to 
the  PDR. 
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MIL-STD-1588  (USAF)  - 30  June  1976 
JOVIAL  ( J3) 

A.  Purpose.  MIL-STD-1588  (USAF)  establishes  the  standard 
specifications  for  the  development  of  compilers  for  the  JOVIAL  ( J3 > 
programming  language. 

B.  Outline  of  Contents 

Chapter  1.  Introduction 

Chapter  2.  Elements 

Chapter  3.  Statements 

Chapter  4.  Declarations 

Chapter  5.  Processing:  Declarations 

Chapter  6.  Programs 

Attachment  1.  Compiler  Specifications 
Attachment  2.  Standard  Air  Force  Glossary 
Attachment  3 . Index 


C.  Comments.  This  standard  describes  in  irfcitail  the  procedure 
for  developing  and  writing  a compiler  program  in  JOVIAL  language. 
The  JOVIAL  language  is  a machine-independent,  procedure-oriented, 
general  purpose  programming  language. 


1 


MIL-STD-1589  (USAF)  - 28  February  1977 
JOVIAL  (J73/1) 

A.  Purpose.  MIL-STD-1589  (USAF)  describes  in  detail  the 
Level  I subset  of  the  J73  JOVIAL  language.  This  standard  is  intended 
for  use  by  programmers  in  coding  J73  JOVIAL  programs.  It  is  an 
implementation  of  AFR  300-10. 

B . Outline  of  Contents. 

Section  1 . Global  Concepts 
Section  2.  Declaration  of  Names 
Section  3.  Statements 

Section  4.  Formulas 
Section  5.  Basic  Elements 
Section  6.  Directives 

Appendix  Cross-Reference  Index 


.. 

* 
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MIL-STD-1679  (Navy)  Draft  - 28  June  1976 
TACTICAL  SOFTWARE  DEVELOPMENT 

A.  Purpose.  This  standard  is  used  by  governmtvit  agencies  for 
guidance  in  the  design  and  development  of  tactical  software. 

B.  Outline  of  Contents 

1.  Scope 

2.  Reference  Documents 

3.  Definitions 

4.  General  Requirements 

5.  Detailed  Requirements 

6.  Miscellaneous 

C.  Comments.  A standard  especially  addressing  tactical  software 
is  necessary  because  of  factors  concerning  this  software  which  are  not 
common  to  general  software,  or  which  carry  a significantly  different 
degree  of  emphasis. 


A. 2. 3 SAMSO  Standards 


SAM  SO  EXHIBIT  73-3  - 6 October  1973 

STANDARD  ENGINEERING  PRACTICES  FOR  COMPUTER  SOFTWARE 
DESIGN  AND  DEVELOPMENT 

A.  Purpose.  This  standard  presents  software  engineering  practices 
for  use  in  Requests  for  Proposal  (RFPs)  and  software  specifications.  It 
references  MIL-STD-482,  483,  and  490,  and  DOD  Manual  4120. 17-M. 

B . Outline  of  Contents 

1.  Scope 

1 . 1 Purpose 

1.2  Use 

1.3  Application 

2.  Referenced  Documents 

3.  Definitions 

3.1  Accountability  (Software) 

3.2  Computer  Software 

3.3  Hardware /Software 

3.4  Standardized  Terms 

4.  General  Requirements 

5.  Detailed  Requirements 

5.1  Software  Management  Procedures  Manual 

5.2  Programming  Practices,  Standards,  and 
Conventions  Manual 

5.3  Software  Accountability  System 

Figure  1.  The  Three  Permitted  Standard  Logic  Structures 

C.  Comments,  Most  of  SAMSO  Exhibit  73-3  concerns  computer 
programming  practices,  standards,  and  conventions.  It  specifies 
characteristics  for  hierarchical  program  design,  execution  order, 
standardized  logic,  and  programming  standards  manual  requirements. 
SAMSO  considers  Exhibit  73-3  to  be  a standard. 
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SAMSO-STD  73-5B  - 2 February  1976 

QUALITY  ASSURANCE  REQUIREMENTS  FOR  SPACE  AND  MISSILE 
SYSTEMS 


A.  Purpose.  This  SAMSO  standard  is  approved  for  use  by  all 
SAMSO  agencies  and  is  intended  as  an  aid  in  interpreting  the  require- 
ments of  MIL-Q-9858A.  The  quality  assurance  requirements  of  this 
standard  supplement  those  of  MIL-Q-9858A. 

B.  Outline  of  Contents 

1 . Scope 

2.  Superseding,  Supplementation  and  Ordering 

2.1  Applicable  Documents 

3.  Quality  Program  Management 

3.1  Organization 

3.1.1  Responsibility 

3. 1.1.1  Quality  Assurance  at  Field  Locations 

3.1.2  Quality  Program  Documentation 

3.1.3  Matrix  of  Quality  Program  Documentation 

3.1.4  Availability  of  Documentation 

3.1.5  Management  Review 

3. 1.5.1  Charting  of  Quality  Trends 

3.1. 5.2  Quality  Audit 

3.2  Initial  Quality  Planning 

3.2.1  Skill  Requirements 

3.3  Work  Instructions 

3.4  Records 

3.5  Corrective  Action 

3.6  Costs  related  to  Quality 

4.  Facilities  and  Standards 

4.1  Drawings,  Documentation  and  Changes 
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SAMSO-STD  73-5B  (Continued) 


4.1.1  Design  Review 

4.1.2  Control  of  Deliverable  Technical  and 
Engineering  Data 

4.1.3  Computer  Program  Quality  Assurance 

4.  1.3.1  Design  Controls 

4. 1.3.2  Drawings,  Documentation  and  Changes 

4 . 1 . 3 . 3 Te  sting 

4. 1.3.4  Corrective  Action 

4.2  Measuring  and  Testing  Equipment 

4.3  Production  Tooling  Used  as  a Media  of  Inspection 

4.4  Use  of  Contractor's  Inspection  Equipment 

4.5  Advanced  Metrology  Requirements 

5.  Control  of  Purchases 

5.1  Responsibility 

5.2  Purchasing  Data 

6.  Manufacturing  and  Control 

6.1  Materials  and  Materials  Control 

6.2  Production  Processing  and  Fabrications 

6.  3 Completed  Item  Inspection  and  Test 

6.4  Handling,  Storage  and  Delivery 

6.5  Nonconforming  Material 

6.6  Statistical  Quality  Control  and  Analysis 

6.7  Indication  of  Inspection  Status 

7.  Coordinated  Government  Contractor  Actions 

7.  1 Government  Inspection  at  Subcontractor  or  Vendor 

Facilities 

7.2  Government  Property 

8.  Notes 
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SAMSO-STD  73-5B  (Concluded) 


C.  Comments.  SAMSO  STD  73 -5B  supersedes  SAMSO  EXHIBIT 
73-5A  of  15  April  1974  and  is  intended  to  satisfy  special  quality  program 
requirements  of  specific  programs  by  supplementing  the  requirements  of 
MIL-Q-9858A.  The  most  applicable  sections  of  this  standard  with  respect 
to  software  quality  assurance  is  paragraph  4.1.3,  "Computer  Program 
Quality  Assurance,  " and  its  associated  paragraphs.  Parallel  use  of 
SAMSO  STD  73-5B  and  MIL-S-52779( AD)  will  result  in  duplication  of  some 
quality  assurance  requirements  unless  duplicative  paragraphs  are 
eliminated  through  tailoring. 


APPENDIX  B 


RSS  BIBLIOGRAPHY 


Within  each  grouping  in  this  appendix,  documents 
are  listed  in  order  of  the  following  subgroups  and 
in  numerical  sequence  within  each  subgroup: 

a.  DODD  / DOD1  / DODR  / DODM 

b.  JCSP 

c.  AFR/AFM/AFP 

d.  AFSCR/AFSCM/AFSCP/AFSC  DH 

e.  SAMSOR/SAMSOP 

f.  NAVMATINST/  SECNAVINST 

g.  ar 

h.  LCC 

i.  T.  O. 

j.  MIL-Q/MIL-S/MIL-M/MIL-T 

k.  MIL-HDBK 

l.  MIL-STD 

m.  SAMSO-STD 

n.  FIPS-PUB 

o.  ANSI 

The  key  documents  summarized  in  Appendix  A 
are  marked  with  an  asterisk  in  this  appendix. 
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B.  1.  GOVERNMENT  DOCUMENTS  PERTAINING  TO 
SOFTWARE  ACQUISITION  ENGINEERING/MANAGEMENT  TASKS 


B.  l.i  ACQUISITION 
DODD  4105.  55 

DODI  4105.  65 

*DODD  5000.  1 
* DODD  5000.  2 
DODI  5030.40 
DODD  5100.  30 

DODD  5105.  19 
DODD  5118.  3 
DODD  5160.  32 
AFR  23-8 
AFR  23-36 
AFR  23-43 

AFR  70-1 


POLICIES 


Selection  and  Acquisition  of  Automatic  Data 
Processing  Resources 

Acquisition  of  Automatic  Data  Processing 
Computer  Program  and  Related  Services 

Major  System  Acquisition 

Major  System  Acquisition  Process 

Government- Wide  ADP  Sharing  Program 

World-Wide  Military  Command  and  Control 
System 

Defense  Communications  Agency 

Assistant  Secretary  of  Defense  (Comptroller) 

Development  of  Space  Systems 

Air  Force  Systems  Command 

Air  Force  Test  and  Evaluation  Center 

Federal  Computer  Performance  Evaluation 
and  Simulation  Center 

Procurement  of  AF  Assigned  Items  Under 
the  DoD  Coordinated  Program 


AFR  70-10 


AFR  70-18 
AFSC  Supplement 

AFR  80-1 

AFR  80-53 
AFSC  Supplement 
SAMSO  Supplement  1 


Procurement  of  Electronic  Equipment  for 
Tri-Service  Use  Under  the  DoD  Coordinated 
Procurement  Program 

Local  Purchase  Program 


Air  Force  Research  and  Development 

Technical  Evaluation  of  Independent  Research 
and  Development 


B.1.1  ACQUISITION  POLICIES  (Concluded) 


AFR  124-8 


AFR  400-27 


;-AF R 800-2  (Cl) 

AFSC  Supplement  1 
Attachments  4,  5 
SAMSO  Supplement  1 

*AFR  800-4 
AFSC/AFLC  Supp.  1 
SAMSO  Supplement  1 

*AFR  800-19 
AFLCM  70-6 
AFSCR  300-1 


MIL-STD-1679(Navy) 

Draft 


Violations  of  Public  Trust  in  Contract, 
Procurement,  and  Other  Matters 

Basic  Policies  and  Principles  for  Inter - 
service.  Interdepartmental  and  Interagency 
Support 

Acquisition  Management  - Program 
Management 


Transfer  of  Program  Management 
Responsibility 


System  or  Equipment  Turnover 

Coordinated  Procurement 

Automatic  Data  Processing  Program 
Management 

Tactical  Software  Development 
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B.  1.  2 ACQUISITION  MANAGEMENT  PRACTICES 


DODI  4100.  31 
DODI  4140.  38 
*DODD  5000.  29 

DODI  5010.  27 

DODD  5100.  40 

DODD  5126.  34 

DODD  7 000.  1 
DODI  7 000.  2 

DODI  7000.  3 
DOOM  7000.6 
JCSP  12  (Volume  I) 
JCSP  14 

JCSP  17 

AFR  26-10 
AFR  27-9 

AFR  57-1 
IMC  76-1  & 2 
SAMSO  Supplement  1 
AFSC  Supplement  1 

AFM  66-18 
AFSC  Supplement  1 


Reports  on  Single  Manager  Operations 

ADP  Management  Information  System 

Management  of  Computer  Resources  in  Major 
Defense  Systems 

Management  of  Automated  Data  System 
Development 

Responsibilities  for  the  Administration  of 
the  Automatic  Data  Processing  Program 

Defense  Procurement  Management  Review 
Program 

Resource  Management  Systems  of  the  DoD 

Performance  Measurement  for  Selected 
Acquisitions 

Acquisition  Management  Systems  Control 

Acquisition  Management  Systems  List 

Information  Exchange  Planning  Guidance 

Computer  System  and  Program  Catalog  for 
Worldwide  Command  and  Control  System 

Management  Procedures  for  the  Worldwide 
Military  Command  and  Control  System 
Standard  Systems 

Manpower  Utilization 

Control  and  Documentation  of  Air  Force 
Programs 

Required  Operational  Capabilities  (ROCS) 


Engineering  and  Technical  Services 
Management  and  Control 
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B.  1. 2 ACQUISITION  MANAGEMENT  PRACTICES  (Continued) 


AFR  70-9 

AFSC  Supplement  I 

MAC  Supplement  I 

AFR  70-11 

AFR  70-12 
AFR  70-13 

AFR  70-15 

AFSC  Supplement  1 

SAM  SO  Supplement  1 

AFR  70-16 

AFR  70-17 

AFP  7 0-19 

AFR  80-2 

AFSC  Supplement  1 
AFR  80-3 

AFR  80-15 
AFSC  Supplement 

AFR  80-51 

AFM  178-6 
AFSC  Supplement  1 

AFR  178-7 
AFSC  Supplement 


, 


Technical  Representative  of  the  Contracting 
Office  (TRCO) 


Implementing  Procedures  for  the  Army 
Single  Department  Procurement  Assignments 

Procurement  Management  Reporting  System 

Implementing  Procedures  for  Single  Depart- 
ment Procurement  of  Commodities  Assigned 
to  the  Department  of  the  Navy 

Source  Selection  Policy 


Contract  Management  in  Major  Program 
Acquisition 

Implementing  Procedures  for  Purchase  of 
Supplies  Assigned  to  DSA  Under  the  DoD 
Coordinated  Procurement  Program 

Contracting  for  Operations  and  Maintenance 
Services 

Documents  Used  in  the  Management  of  Air 
Force  Research  and  Development 

Management  of  Air  Force  In-House  Research 
and  Development  Labs 

Participation  in  Certain  NATO  Groups  on 
Research,  Development,  Production,  and 
Logistics  Support  of  Equipment 

Management  of  R&D  Requirements  in  the 
Personnel,  Training,  and  Education  Program 

Resource  Manager's  Handbook 


Management  and  Control  of  Information 
Requirements 
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B.  1. 2 ACQUISITION  MANAGEMENT  PRACTICES  (Continued) 


*AFR  3 00-2 

AFM  300-6 
AFSC  Supplement 
SAMSO  Supplement  1 

AFR  300-7 

AFM  3 00-12 
AFSC  Supplement 

AFR  600-1 
AFSC  Supplement 

AFR  800-10 

*AFR  800-14  (Volume 
Supplement  1 
AFSC  Supplement 

*AFR  800-14  (Volume 

AFSCM  70-1 

AFSCR  70-2 
AFSCR  70-7 
AFSCR  70-10 
AFSCR  70-11 

AFSCM  70-480 
AFSCR  80-15 
AFSCM  171-265 
AFSCM  171-271 


Management  of  the  USAF  Automatic  Data 
Processing  Program 

Automatic  Data  Processing  (ADP)  Resource 
Management 


Automatic  Data  Processing  Planning  Concepts 

Procedures  for  Managing  Automatic  Data 
Processing  Systems 

Development,  Selection  and  Application  of 
Management  Control  Systems 

Management  of  Multi-Service  Systems, 
Programs  and  Projects 

I)  Management  of  Computer  Resources  in 
Systems 


II)  Acquisition  and  Support  of  Computer 
Resources  in  Systems 

Functions  and  Responsibilities  of  AFSC 
PR-MIPR  Control  Offices  and  the  AFSC 
MIPR  Liaison  Office 

AFSC  Business  Strategy  Panel 

AFSC  Procurement  Evaluation  Panel 

Physically  Completed  Contracts 

Surveillance  of  Management  Control  Systems 
and  Financial  Reporting  on  Selected  Acquisi- 
tions 

Procurement  Action  Reporting  System 

R&D  Source  Selection  Policy  and  Guidance 

Acquisition  of  R&D  Services 

AFSC  Aerospace  Resources  and  Configuration 
System 
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B.  1. 2 ACQUISITION  MANAGEMENT  PRACTICES  (Concluded) 


AFSCM  171-480 
(Two  Volumes) 

AFSCM  171-490 

AFSCR/AFLCR  800-2 

AFSCP  800-3 

AFSCR  800-14 
(AFLCR  800-14) 


Procurement  Action  Reporting  System 

Automated  Reports  Management  System 

Management  of  Multi-Service  Systems, 
Programs  and  Projects 

A Guide  to  Program  Management 

Joint  AMC/NMC/AFLC/AFSC  List  of 
Authorized  Acquisition  Management  Systems 
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B.  1.3  RFP  PACKAGE 
AFSCP  70-4 
AFSCP  800-6 
SAMSOR  70-1 
*SAMSOR  70-2 


Request  for  Proposal  Preparation  Guide 
Statement  of  Work  Preparation  Guide 
Solicitation/Contract  Terms  and  Conditions 
Request  for  Proposal  Policy 
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B.  1.4  MANAGEMENT  CONTROLS 


B.  1.4.1  Visibility 
DODI  4105.  64 


*DODD  5000.  19 


*DODD  5000.  19-L 
Supplement 

DODD  5010.  28 


'!MIL-  STD  1521A 


MIL- STD  1602 


AFR  800-5 
AFSC  Supplement  1 

AFSCR  70-12 
SAMSO  Supplement  1 

AFSCR  800-1 


AFSCR  800-18 


Technical  Representation  at  Contractor 
Facilities 

Policies  for  the  Management  and  Control  of 
DoD  Information  Requirements 

Acquisition  Management  Systems  and  Data 
Requirements  Control  List  (AMSDL) 

Department  of  Defense  Management  Review 
and  Improvement  Program 

Technical  Reviews  and  Audits  for  Systems, 
Equipment  and  Computer  Programs 

Requirements  for  Progress  Reports  for 
R&D  Equipment 

Selected  Acquisition  Reports  (SARs) 


AFSC  Procurement  Summary  Report 


Command  Review  of  Systems  Acquisition 
Programs  and  Test  Resources 

Joint  Operational  and  Technical  Review  (JOTR) 


B.  1.4.2  Cost  and  Schedule  Control 


DODI  5000.  22 


DODI  7 000.  10 


DODI  7 000.  11 


DODI  7041.  3 


AFP  70-14 


Guide  to  Estimating  Costs  of  Information 
Requirements 

Contract  Cost  Performance  Funds  Status 
and  Cost  Schedule  Status  Reports 

Contractor  Cost  Data  Reporting 

Economic  Analysis  and  Program  Evaluation 

Probability  of  Incurring  Estimated  Cost 
(PIECOST) 


- 141  - 


B.  1.4.2  Cost  and  Schedule  Control  (Concluded) 


AFR  173-1 
AFSC  Supplement  1 

AFR  173-10 
(Three  Volumes) 

AFR  173-11 

AFR  175-4 
SAMSO  Supplement  1 
AFSC  Supplement  1 

AFR  177-13 

AFM  177-100 


AFR  178-1 


AFR  800-6 
AFSC  Supplement 
IMC  77-1 

*AFR  800-11 
SAMSO  Supplement  1 
IMC  76-1 

AFSCM  173-1 

AFSCP  173-5 
(AFLCP  173-5) 

AFSCP  173-6 
(AFLCP  173-6) 

AFSCP  800-15 
(AFLCP  800-15) 

AFSCP  800-19 
(AFLCP  800-19) 


LCC-3 


MIL-STD-1641 


Management  of  the  Cost  Analysis  Program 


USAF  Cost  and  Planning  Factors 


Independent  Cost  Analysis  Program 
Auditing  in  the  Air  Force 


Accounting  for  Research  and  Development 

General  Principles,  Standards,-  and  Policies 
of  the  Air  Force  Accounting  and  Finance 
System 

Economic  Analysis  and  Program  Evaluation 
for  Resource  Management 

Program  Control  - Financial 


Life  Cycle  Costing  (LCC) 


Cost  Estimating 

Cost/Schedule  Control  Systems  Criteria 


C/SCSC  Joint  Surveillance  Guide 


Contractor  Cost  Data  Reporting  (CCDR) 
System 

Joint  Design-to-Cost  Guide:  A Conceptual 
Approach  for  Major  Weapon  System 
Acquisition 

Life  Cycle  Costing  Guide  for  System 
Acquisition 

Preparation  of  PERT/T'me  Networks  and 
Reports  for  Training  Device  Contracts 
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B.  1.4.4  Data  Management  (Concluded) 

r 

TO  00-5- i 

Air  Force  Technical  Order  System 

TO  00-5-2 

TOP  Supplement  100 

Technical  Order  Distribution  System 

TO  00-5-15 

Time  Compliance  Technical  Order  System 

I 

MIL-M-387  84A 

General  Requirement  for  Preparation  of 
Technical  Manuals 

MIL-  T-38804 

Time  Compliance  Technical  Orders 

*MIL- STD-490 

Specification  Practices 

MIL-STD-83  1 

Preparation  of  Test  Reports 

MIL- STD- 885  B 

Procurement  Data  Packages 

*MIL- STD-83490 

Specifications,  Types  and  Forms 

B.  1.4.  5 Integrated  Logistics  Support 

AFP  800-7 

Integrated  Logistics  Support  Implementation 
Guide  for  DoD  Systems  and  Equipment 

AFR  800-8 

AFSC  Supplement 

SAMSO  Supplement  1 

Integrated  Logistics  Support  (ILS)  Program 
for  Systems  and  Engineering 

AFSCP  800-21 

A Guide  to  Program  Managers:  Implementing 
Integrated  Logistics  Support 

AFSCR  800-24 
(AFLCR  800-24) 

Standard  Integrated  Support  Management 

System 

MIL- STD-1 3 88/1 

Logistic  Support  Analysis 

MIL- STD-1 3 88/2 

Logistic  Support  Analysis  Data  Definition 

B.  1.4.6  Communications 

| 

DODD  4630.  1 

Programming  of  Major  Telecommunication 
Requirements 

AFR  100-8 

AFSC  Supplement 

Programming  of  Major  Telecommunication 
Requirements 

i 

| I 
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B.  1.4.6  Communications  (Concluded) 


AFM  100-20 

AFSC  Supplement 

IMC  76-1  and  77-1 

SAMSO  Supplement  1 

Management  of  Electrical  Record  Communi- 
cation 

AFR  100-41 

Handling  of  Message  Traffic  for  Other 
Government  Agencies 

B.  1.4.7  Development  Facilities  and  Resources 

DODI  4140.41 

Government  Owned  Material  Assets  Utilized 
as  Government  Furnished  Material  for  Major 
Acquisition  Programs 

B.  1. 4.  8 Standardization 

DODD  4120.  3 

Defense  Standardization  Program 

*DOD  4120.  3-M 

Standardization  Policies,  Procedures  and 
Instructions 

DODI  4120.  16 

COBOL  Compiler  Validation 

DODD  4630.  5 

Compatibility  and  Commonality  of  Equipment 
for  Tactical  Command  and  Control  and 
Communications 

DODD  5000.  9 

Standardization  of  Military  Terminology 

DODD  5000.  11 

Data  Elements  and  Data  Codes  Standardization 
Procedures 

DODI  5000.  12 

Data  Elements  and  Data  Codes  Standardization 
Procedures 

DODI  5000.  18 

Implementation  of  Standard  Data  Elements  and 
Related  Features 

AFM  11-1  (Volume  I) 

U.  S.  Air  Force  Glossary  of  Standardized 

Te  rms 

AFM  11-1  (Volume  II) 

Air  Force  Glossary  of  Comptroller  Terms 

AFM  11-1  (Volume  III) 

Communications  Electronics  Terminology 

III  — ~ 
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B.  1.4.8  Standardization  (Concluded) 


❖AFR  73-1  Defense  Standardization  Program 

AFSC  Supplement  1 

AFM  300-4  (12  Volumes)  Data  Elements  and  Codes 
AFSC  Supplement 
( Volume  I only) 


AFR  3 00-5  Standardization  of  Data  Elements  and 

AFSC  Supplement  Related  Features 

SAMSO  Supplement  1 


JCSP  7 Worldwide  Military  Command  and  Control 

System  Standards 

JCSP  10  Tactical  Command  and  Control  and  Communi- 

cations System  Standards 


MIL-STD-680 


Contractor  Standardization  Plans  and 
Management 


B.i.4.9  Configuration  Control 


❖DODD  5010.  19 
DODD  5010.  20 


AFR  57-4 
AFSC  Supplement 

❖AFR  65-3 
AFSC  Supplement  1 


Configuration  Management 

Configuration  Management  Implementation 
Guidance 

Retrofit  Configuration  Changes 
Configuration  Management 


AFSCM  171-380 
❖AFSCP  800-7 
AFSCM  800-380 
❖NAVMATINST 


❖AR  7 0-37  Draft 


Configuration  Status  Accounting  System 
Configuration  Management 

Configuration  Status  Accounting  System  (CSAS) 

Configuration  Management  of  Computer 
Software  Associated  with  Tactical  Digital 
Systems  and  Other  Technical  Computer 
Systems 

Configuration  Management 
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B.  1.4.9  Configuration  Control  (Concluded) 


•MIL-STD-130E 


*MIL-  STD-4  80 


•MIL-  STD-481  A 


•MIL-  S TD-482A 


•MIL- STD-483  (USAF) 


MIL-STD-1456 


Identification  Marking  of  U.S.  Military 
Property 

Configuration  Control- Engineering  Changes, 
Deviation*  and  Waivers 

Configuration  Control- Engineering  Changes, 
Deviations  and  Waivers  (Short  Form) 

Configuration  Status  Accounting  Data  Elements 
and  Related  Features 

Configuration  Management  Practices  for 
Systems,  Equipment,  Munitions  and 
Computer  Programs 

Contractor  Configuration  Management  Plans 


B.  1.4.  10  Quality  Control 


B.  1.4.  10.  1 Quality  Assurance 


•AFR  74-1 

AFR  74-6 

AFR  74-15 

AFR  80-38 
AFSC  Supplement 

AFSCR  7<*-6 
SAMSO  Supplement  1 

•SAMSOP  74-2 


Quality  Assurance  Program 

Reporting  of  Quality  Deficiency  Data 

Procurement  Quality  Assurance 

Management  of  the  Air  Force  Survivability 
Program 

Procurement  Quality  Assurance  for  System 
Programs 

Contractor  Software  Quality  Assurance 
Evaluation  Guide 


•MIL-Q-9858A 
•MIL-S-52779  (AD) 


MIL-  STD-1 5 3 5 A 


•SAMSO-STD  73-5B 


Quality  Program  Requirements 

Software  Quality  Assurance  Program 
Requirements 

Supplier  Quality  Assurance  Program 
Requirements 

Quality  Assurance  Requirements  for  Space 
and  Missile  Systems 
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B. 1.4. 10.2  Reliability  and  Maintainability 

AFR  80-5  Reliability  and  Maintainability  Programs 

AFSC  Supplement  for  Systems,  Subsystems,  Equipment  and 

Munitions 

MIL-HDBK-472  Maintainability  Prediction 


MIL- STD-47  0 

MIL- STD-471  A 
MIL- STD-6  9 OB 
MIL- STD-72  IB 

MIL- STD-7  56A 
MIL- STD-7  57 

MIL- STD-78  IB 
MIL-STD-7  85A 

MIL- STD- 13  04 A 


Maintainability  Program  Requirements  (for 
Systems  and  Equipment) 

Maintainability  Demonstration 

Failure  Rate  Sampling  Plans  and  Procedures 


Definition  of  Effectiveness  Terms  for 
Reliability,  Maintainability,  Human  Factors 
and  Safety 


Reliability  Prediction 


Reliability  Evaluation  and  Demonstration 
Data 


. 


Reliability  Test  Exponential  Distribution 

Reliability  Program  for  Systems  and 
Equipment  Development  and  Production 


Reliability  Report 


B.  1.4.  10.3  Security 
DODD  5200.  5 
DODD  5200.  28 

DO  DM  5200.  28-M 
AFR  8-9 

AFR  66-30 

AFR  80-7 
AFSC  Supplement 


Communications  Security 

Security  Requirements  for  Automatic  Data 
Processing  (ADP  Systems) 

ADP  Security  Manual 

USAF  Communications  Security  and  Emanations 
Security  Publications 

Product  Improvement  Programs  for  Operational 
Equipment 

Communications  Security  Research,  Develop- 
ment, Test  and  Evaluation  (COMSEC  RDT&E) 
Procedures 
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B.  1.4.  10.3  Security  (Concluded) 
AFR  100-27 


AFR  100-45 

Vol.  I (Unclassified) 

Vol.  II  (Secret  COMSEC) 

AFR  205-1 
AFSC  Supplement 
SAM  SO  Supplement 

AFP  205-2 

AFR  205-25 

AFR  205-28 
AFSC  Supplement  1 

AFR  207-1 
AFSC  Supplement  1 
IMC  77-1,  77-2,  77-3 
to  the  Supplement 

AFM  207-3 

AFM  207-21 


AFR  300-8 
AFSC  Supplement  1 

AFSCP  207-1 


Release  or  Disclosure  of  Unclassified 
Messages 

Communications  Security  Policies, 
Procedures,  and  Instructions 


Information  Security  Program 


Communications  Security  and  Transmission 
Security 

Safeguarding  the  Single  Integrated  Opera- 
tional Plan  (SIOP) 

Communications  Security  for  Nuclear 
Command  and  Control  Communications 

The  Air  Force  Physical  Security  Program  . 


Aircraft  Systems  Security  Standards 

System  Security  Standard- Command  and 
Control  and  Communication  System 

Security  Requirements  for  Automatic  Data 
Processing  Systems  (APDS) 

System  Security  Engineering 


B.  1.4.  11  Production  Planning 
AFR  800-9 


AFSCM  84-3 
MIL- STD-1 528 


Production  Management  in  the  Acquisition 
Life  Cycle 

Production  Management 
Production  Management 
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B.  2 GOVERNMENT  DOCUMENTS  PERTAINING  TO 
SOFTWARE  ENGINEERING /DEVELOPMENT  TASKS 

B.  2.  1 SYSTEM  ENGINEERING 

DODI  5010.8  DoD  Value  Engineering 

DODD  5010.  15  Defense  Integrated  Management  Engineering 

System 

DODI  7110.  2 Budget  Guidance  for  Value  Engineering 


AFR  122-1 
AFSC  Supplement 
SAM  SO  Supplement  1 

AFR  122-9 


AFR  122-10 


AFR  127-8 
AFSC  Supplement 

AFR  127-13 
AFSC  Supplement 

AFR  320-1 
AFSC  Supplement 
SAMSO  Supplement  1 

*AFR  800-3 

AFR  800-15 
AFSC  Supplement  1 

AFSCR  8-4 
SAMSO  Supplement  1 

AFSCR  80-17 
(AFLCR  80-17) 
SAMSO  Supplement  1 

MIL-K-46855A 


The  Air  Force  Nuclear  Safety  Program 


The  Nuclear  Safety  Crosscheck  Analysis  and 
Certification  Program  for  Weapon  Systems 
Software 

Nuclear  Weapon  Systems  Safety  Design  and 
Evaluation  Criteria 

Responsibilities  for  USAF  System  Safety 
Engineering  Programs 

Responsibilities  for  the  USAF  Aerospace 
Safety  Program 

Air  Force  Value  Engineering  Program 


Engineering  for  Defense  Systems 

Human  Factors  Engineering  and  Management 


AFSC  Design  Handbooks 


Air  Force  Engineering  Responsibility  for 
Systems  and  Equipment 


Human  Engineering  Requirements  for  Military 
Systems,  Equipment  and  Facilities 
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B.  2.  1 SYSTEM  ENGINEERING  (Concluded) 


MIL-STD-415D 


♦MIL-STD-499A 
MIL- STD-87  6 A 


MIL-STD-882A 


MIL- STD-1 3 7 9A 
MIL-  S TD- 1 47  2 B 


MIL- STD-1631  A 


Design  Criteria  for  Test  Provisions  for 
Electronic  Systems  and  Associated 
Equipment 

Engineering  Management 

Digital  Computation  Systems  for  Real  Time 
Training  Simulators 

Requirement  for  System  Safety  Program  for 
Systems  and  Associated  Subsystems  and 
Equipment 

Training  Operations  and  Training  Data 

Human  Engineering  Design  Criteria  for 
Military  Systems  Equipment  and  Facilities 

Procedure  for  Selection  of  Electronics  and 
Electrical  Parts  During  Equipment  Design 


B.  2.  2 PROGRAMMING  STANDARDS 


*DODD  5000.  31 


AFR  3 00-10 
AFR  800-12 


AFSCR  65-8 


Interim  List  of  DoD  Approved  High  Order 
Programming  Languages  (HOL) 

Computer  Programming  Languages 

Acquisition  of  Support  Equipment 

Utilization  of  Assets  as  Government 
Furnished  Material 


*MIL- STD-15 88  (USAF)  JOVIAL  (J3) 

♦MIL-STD-1589  (USAF)  JOVIAL  (J73/1) 


FIPS  PUB  1 


FIPS  PUB  15 


FIPS  PUB  20 


Code  for  Information  Interchange  (also 
ANSI  X3. 4-1968) 

Subsets  of  the  Standard  Code  for  Information 
Interchange 

Guidelines  for  Describing  Information  Inter- 
change Formats 
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B.  2.  2 PROGRAMMING  STANDARDS  (Concluded) 


FIPS  PUB  24 

FIPS  PUB  29 

ANSI  X3.  9-1966 
ANSI  X3.  10-1966 
ANSI  X3 . 23-1974 


Flowchart  Symbols  and  Their  Usage  in 
Information  Processing  (also  ANSI  X3.  5-1970) 

Interpretation  Procedures  for  Federal 
Standard  COBOL 

FORTRAN 

Basic  FORTRAN 

COBOL 


B.  2.  3 SOFTWARE  DESIGN  STANDARDS 
* SAM  SO  Exhibit  73-3 


SAM  SO- STD  77-9 


Standard  Engineering  Practices  for  Computer 
Software  Design  and  Development 

Software  Design  Standards  for  the  MX  Weapon 
System 


B.2.4  COMPUTER  PROGRAM  TESTING 
♦AFSC  DH4-2  Electronic  Systems  Test  and  Evaluation 

B.  2.  5 OPERATIONAL  TESTING 


♦DODD  5000.3 

♦AFR  80-14 
AFSC  Supplement 
SAMSO  Supplement  1 

MIL- STD-883 
MIL-  STD-1 3 09A 
MIL-STD-i  519 


Test  and  Evaluation 
Test  and  Evaluation 


Test  Methods  and  Procedures  for  Micro 
Electronics 

Definition  of  Terms  for  Automatic  Electronic 
Test  and  Checkout 

Preparation  of  Test  Requirement  Documents 
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B.  2.  6 TRANSFER  AND  TURNOVER 


AFR  800-4  Transfer  of  Program  Management 

AFSC  Supplement  1 Responsibilities 

SAMSO  Supplement  1 

AFR  800-19  System/ Equipment  Turnover 

B.  2.  7 OPERATION  AND  MAINTENANCE 

AFSCM  171-267  AFSC  Maintenance  Performance  Monitoring 

System 

MIL-STD-1345A  Data  Measurement  in  Support  of  Maintenance. 

Calibration  and  Repair  of  Electronic 
Equipment 

MIL-STD-1390B  Level  of  Repairs 
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RELATED  GUIDANCE  DOCUMENTS 


PieteM  mi 
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Additional  information  on  the  topics  of  this  guidebook  may  be  found 
in  the  following  documents: 

a.  SAMSO-GB-1,  "Guide  for  Selecting,  Tailoring,  and  Applying 
Specs  and  Standards,  " prepared  by  the  Aerospace  Corporation 
for  Department  of  the  Air  Force,  Headquarters,  Space  and 
Missile  System  Organization  (AFSC),  dated  3 January  1977. 

b.  ESD- TR-75-91,  "Software  Acquisition  Management  Guidebook: 
Regulations,  Specifications,  and  Standards,  " prepared  by  The 
Mitre  Corporation  for  Deputy  for  Command  Management 
Systems,  Electronic  Systems  Division,  Air  Force  Systems 
Command,  dated  October  1975.  (Mitre  Document  Number: 
MTR-3080.  U.  S.  Department  of  Commerce  National 
Technical  Information  Series  Number;  AD-A016  401.  ) 

c.  ASD- TR-76-1 1,  "Summary  of  Software  Related  Standards  and 
Regulations,  11  Volume  III  of  Management  Guide  to  Avionics 
Software  Acquisition,  prepared  by  Logicon  for  Aeronautical 


Systems  Division,  Air  Force  Systems  Command,  dated  June 
1976. 

ESD- TR-76-1 59,  "An  Air  Force  Guide  to  Software  Documen- 
tation Requirements,  " prepared  by  the  Mitre  Corporation  for 
Deputy  for  Command  and  Management  Systems,  Electronic 
Systems  Division,  Air  Force  Systems  Command,  Dated  June 
1976. 

RADC- TR-74-300,  Volume  VII,  "Documentation  Standards," 
part  of  Structured  Programming  Series,  prepared  by  IBM  for 


Rome  Air  Development  Center,  Air  Force  Systems  Command, 
and  U.  S.  Army  Computer  Systems  Command,  dated  September 
1975.  (NTIS  Number:  ADA008-639/7GI.  ) 
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APPENDIX  D 
LIST  OF  DEFINITIONS 

The  following  set  of  definitions  of  basic  computer 
terms  is  particularly  clear  and  coherent.  These 
definitions  are  extracted  from  the  May  1975  draft 
of  the  Johns  Hopkins  University  Applied  Physics 
Laboratory  "DOD  Weapon  Systems  Software 
Management  Study."  They  were  proposed  by  APL 
to  the  DOD  Weapon  System  Software  Management 
Steering  Committee  for  adoption  as  "working 
standard  definitions  in  the  Department  of  Defense." 
Their  current  status  in  DOD  is  unknown. 


LIST  OF  DEFINITIONS 


1.  Computer:  Electronic  machinery  which,  by  means  of  stored 
instructions  and  data,  performs  rapid,  often  complex  calculations 
or  compiles,  correlates  and  selects  data.  Examples:  Analog  and 
digital  processors,  data  processors,  information  processors, 
real-time  control  processors,  electronic  calculators,  hybrid 
computers  and  communications  processing. 

2.  Computer  Equipment /Computer  Hardware:  Devices  capable  of 
accepting  ana  storing  computer  data,  executing  a systematic 
sequence  of  operations  on  computer  data  or  producing  computer 
outputs.  Such  devices  can  perform  substantial  interpretation, 
computation,  communication,  control,  or  other  logical  functions. 
Examples:  central  processing  units,  terminals,  printers,  analog/ 
digital  converters,  tape  drives,  disks,  and  drums. 

3.  Computer  Supplies:  Consumables  designated  specifically  for  use 
in  normal  operation  of  computer  systems  such  as  magnetic  or 
paper  tape,  special  forms,  punch  cards,  printer  paper  and 
ribbons. 

4.  Computer  Software:  A combination  of  associated  computer  programs 
and  computer  data  required  to  command  the  computer  equipment  to 
perform  computational  or  control  functions. 

5.  Computer  Program:  A series  of  instructions  or  statements  in  a 
form  acceptable  to  computer  equipment,  designed  to  cause  the 
computer  equipment  to  execute  an  operation  or  operations.  Com- 
puter programs  include  operating  systems,  assemblers,  compilers, 
interpreters,  data  management  systems,  utility  programs,  sort- 
merge  programs,  and  maintenance/diagnostic  programs,  as  well 
as  applications  programs  such  as  payroll,  inventory  control, 
operational  flight,  satellite  navigation,  automatic  test,  crew 
simulator,  and  engineering  analysis  programs.  Computer  programs 
may  be  either  machine-dependent  or  machine-independent,  and  may 
be  general-purpose  in  nature  or  be  designed  to  satisfy  the  require- 
ments of  a specialized  process  or  a particular  user. 

6.  Computer  Data:  A representation  of  facts,  concepts,  or  instructions 
in  a structured  form  suitable  for  acceptance,  interpretation  or  pro- 
cessing by  communication  between  computer  equipment.  Such  data 
can  be  external  to  (in  computer- readable  form)  or  resident  within 
the  computer  equipment  and  can  be  in  the  form  of  analog  or  digital 
signals. 
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LIST  OF  DEFINITIONS  (Continued) 


7.  Computer  Data  Sourcee:  Device*,  media,  and  associated  actions 
that  generate  computer  data  for  use  by  a computei  system.  In- 
cludes devices  producing  analog  or  digital  signals;  punched  cards 
or  magnetic  tape;  and  associated  procedures,  processes,  or 
methods  used  to  initiate,  modify,  or  terminate  the  operation  of  a 
computer  system. 


8.  Computer  Equipment  Output  *>  Computer  data,  computer  control 
signals  or  computer  information  transmitted  to  any  device  or 
medium  internal  or  external  to  the  computer  system. 

9.  Computer  Information:  Ihe  meaning  assigned  to  computer  equip- 
ment outputs  by  humans  through  the  means  of  known  conventions 
used  in  data  representation. 

1 0.  Computer  Control  Signals:  Computer  equipment  outputs  in  the 
form  of  electrical,  optical  or  audio  signals  used  to  initiate, 
modify,  or  terminate  the  operation  of  non- computer  devices 
external  to  the  computer  system, 

11.  Computer  System;  An  interacting  assembly  consisting  of  computer 
equipment,  computer  programs,  and  computer  data. 

12.  Embedded  Computer  System  (ECS);  An  embedded  computer 
system  is  a computer  system  that  is  integral  to  an  electro- 
mechanical system  such  as  a combat  weapons  system,  tactical 
system,  aircraft,  ship,  missile,  spacecraft,  certain  command 
and  control  systems,  civilian  systems  such  as  a rapid  transit 
system,  and  the  like.  Embedded  computer  systems  are  consid- 
ered different  than  automatic  data  processing  systems  (ADPS) 
primarily  in  the  context  of  how  they  are  developed,  acquired  and 
operated  in  a using  system.  The  key  attributes  of  an  enbedded 
computer  system  are: 

a.  It  is  a computer  system  that  is  physically  incorpo- 
rated into  a larger  system  whose  primary  function 
is  not  data  processing. 

b.  It  is  integral  to  such  a larger  system  from  a design, 
procurement  or  operations  viewpoint. 

c.  Its  outputs  generally  include  information,  computer 
control  signals  and  computer  data. 


- 159  - 


t is’'/?'  -vA  > ' * 

' t hj  W i U,  • 


A 


LIST  OF  DEFINITIONS  (Concluded) 


13 . Computer  Software  Documentation:  Technical  data,  including 
computer  listings  and  printouts,  In  human-readable  form  which: 
(1)  documents  the  design  or  details  of  computer  software,  (2) 
explains  the  capabilities  of  the  computer  software,  or  (3 ) pro- 
vides operating  instructions  for  using  the  computer  software  to 
obtain  desired  results  from  computer  equipment. 

14.  Computer  System  Documentation:  Information  that  describes  the 

details  of  the  computer  system  over  its  life  cycle. 
Documentation  includes,  but  is  not  limited  to,  equipment  design 
specifications,  engineering  drawings,  operators  manuals, 
technical  orders,  computer  software  documentation,  systems 
specifications,  run  diagrams,  and  interface  specifications. 

15.  Computer  System  Resources:  The  totality  of  computer  equip- 
ment, computer  programs,  computer  data,  associated  computer 
documentation,  contractual  services,  personnel  and  computer 
supplies. 
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